diff --git a/ISSUE_TEMPLATE/membership.md b/.github/ISSUE_TEMPLATE/membership.md similarity index 85% rename from ISSUE_TEMPLATE/membership.md rename to .github/ISSUE_TEMPLATE/membership.md index bb0977a1..a4758eda 100644 --- a/ISSUE_TEMPLATE/membership.md +++ b/.github/ISSUE_TEMPLATE/membership.md @@ -16,12 +16,13 @@ e.g. (at)example_user ### Requirements -- [ ] I have reviewed the community membership guidelines https://github.com/open-feature/community/CONTRIBUTOR_LADDER.md +- [ ] I have reviewed the community membership guidelines https://github.com/open-feature/community/blob/main/CONTRIBUTOR_LADDER.md - [ ] I have enabled 2FA on my GitHub account. See https://github.com/settings/security - [ ] I have subscribed to the [Slack channel](https://cloud-native.slack.com/archives/C0344AANLA1) (use http://slack.cncf.io/ to get an invite) - [ ] I am actively contributing to 1 or more OpenFeature subprojects - [ ] I have two sponsors that meet the sponsor requirements listed in the community membership guidelines. Among other requirements, sponsors must be approvers or maintainers of at least one repository in the organization and not both affiliated with the same company - [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application +- [ ] I have created a pull request, adding myself to the `members` of the organization within the [community configuration](https://github.com/open-feature/community/blob/main/config/open-feature/org.yaml/) ### Sponsors diff --git a/.github/workflows/peribolos.yaml b/.github/workflows/peribolos.yaml new file mode 100644 index 00000000..39b0b981 --- /dev/null +++ b/.github/workflows/peribolos.yaml @@ -0,0 +1,41 @@ + +name: Organization Configuration + +on: + push: + branches: [ main ] + pull_request: + branches: [ main ] + paths: + - 'tools/**' + - 'config/**' + schedule: + - cron: "0 0 * * *" + +env: + PERIBOLOS_ARGS: "--fix-org --fix-org-members --fix-repos --fix-team-members --fix-teams --fix-team-repos --maximum-removal-delta=1 --github-allowed-burst=300 --github-hourly-tokens=1000 --allow-repo-archival" + +jobs: + build: + runs-on: ubuntu-latest + steps: + - name: Checkout code + uses: actions/checkout@v4 + + - name: Generating Peribolos configuration + uses: docker://ghcr.io/open-feature/community-tooling:v0 + + - name: Preparing credentials + run: echo ${{ secrets.PERIBOLOS_GH_TOKEN }} >> github-token # a secret with the user token to be used for execution + + - name: Run Peribolos Configuration Verification + if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository + uses: docker://ghcr.io/dynatrace-innovationlab/peribolos:v0 + with: + args: ${{ env.PERIBOLOS_ARGS }} --github-token-path github-token --config-path config/peribolos.yaml + + - name: Apply Peribolos Configuration + if: github.event_name != 'pull_request' + uses: docker://ghcr.io/dynatrace-innovationlab/peribolos:v0 + with: + args: ${{ env.PERIBOLOS_ARGS }} --github-token-path github-token --config-path config/peribolos.yaml --confirm diff --git a/ADOPTERS.md b/ADOPTERS.md index 8b9d2f31..e6c2c3a5 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -1,13 +1,19 @@ -# OpenFeature Adopters +# Adopters A non-exhaustive, alphabetized list of organizations that have adopted OpenFeature. -| Company | Components | Notes | -| ------------------------------------------------ | ------------------------------- | :-----------------------------------------------------------------------------------------------------------------: | -| [Dynatrace](https://www.dynatrace.com) -| [Ebay](https://www.ebay.com) | | | -| [Schweitzer Engineering Labs](https://selinc.com) | | | -| [Tapico](https://tapico.io) | | | -| [Utility Warehouse](https://uw.co.uk) | | | +| Company | Logo | Notes | +| ------------------------------------------------- | ---------- | :---: | +| [codecentric](https://www.codecentric.de/) | | | +| [Dynatrace](https://www.dynatrace.com) | | | +| [Ebay](https://www.ebay.com) | | | +| [FNZ](https://fnz.com) | | | +| [Minder](https://mindersec.github.io/) | | An OpenSSF project | +| [Proofpoint](https://www.proofpoint.com) | | | +| [Redpanda](https://www.redpanda.com) | | | +| [Schweitzer Engineering Labs](https://selinc.com) | | | +| [Tapico](https://tapico.io) | | | +| [Utility Warehouse](https://uw.co.uk) | | | +| [Virtru](https://www.virtru.com) | | | -_Sorted alphabetically by first name_ +_Sorted alphabetically by name_ diff --git a/CODEOWNERS b/CODEOWNERS new file mode 100644 index 00000000..59912249 --- /dev/null +++ b/CODEOWNERS @@ -0,0 +1,5 @@ +# These owners will be the default owners for everything in +# the repo. Unless a later match takes precedence + +# The config folder is used by Peribolos to configure org permissions +/config/ @toddbaert @beeme1mr diff --git a/CONTRIBUTOR_LADDER.md b/CONTRIBUTOR_LADDER.md index 66e31bb5..f32ee748 100644 --- a/CONTRIBUTOR_LADDER.md +++ b/CONTRIBUTOR_LADDER.md @@ -1,143 +1,122 @@ -# OpenFeature Contributor Ladder - - -* [Contributor Ladder](#contributor-ladder) - * [Community Participant](#community-participant) - * [Contributor](#contributor) - * [Organization Member](#organization-member) - * [Triager](#triager) - * [Approver](#approver) - * [Maintainer](#maintainer) -* [Inactivity](#inactivity) -* [Involuntary Removal](#involuntary-removal-or-demotion) -* [Stepping Down/Emeritus Process](#stepping-downemeritus-process) -* [Contact](#contact) - - -## Contributor Ladder +# Contributor Ladder Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. Each of the roles is organized into lists of three types of things. "Responsibilities" are things that a contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to. - -### Community Participant +## Community Participant A Community Participant engages with the project and its community, contributing their time, thoughts, etc. Community participants are usually users who have stopped being anonymous and started being active in project discussions. -* Responsibilities: - * Must follow the [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) -* How users can get involved with the community: - * Participating in community discussions - * Submitting bug reports - * Commenting on issues - * Trying out new releases - * Attending community events - * Reviewing pull requests +- Responsibilities: + - Must follow the [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +- How users can get involved with the community: + - Participating in community discussions + - Submitting bug reports + - Commenting on issues + - Trying out new releases + - Attending community events + - Reviewing pull requests - -### Contributor +## Contributor A Contributor contributes directly to the project and adds value to it. Contributions need not be code. People at the Contributor level may be new contributors, or they may only contribute occasionally. -* Responsibilities include: - * Follow the [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) - * Follow the project contributing guide -* Requirements (one or several of the below): - * Report and sometimes resolve issues - * Occasionally submit PRs - * Contribute to the documentation - * Show up at meetings, takes notes - * Answer questions from other community members - * Submit feedback on issues and PRs - * Test releases and patches and submit reviews - * Run or helps run events - * Promote the project in public - * Help run the project infrastructure -* Privileges: - * Invitations to contributor events - * Eligible to become an Organization Member - - -### Organization Member +- Responsibilities include: + - Follow the [CNCF CoC](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) + - Follow the project contributing guide +- Requirements (one or several of the below): + - Report and sometimes resolve issues + - Occasionally submit PRs + - Contribute to the documentation + - Show up at meetings, takes notes + - Answer questions from other community members + - Submit feedback on issues and PRs + - Test releases and patches and submit reviews + - Run or helps run events + - Promote the project in public + - Help run the project infrastructure +- Privileges: + - Invitations to contributor events + - Eligible to become an Organization Member + +## Organization Member An Organization Member is an established contributor who regularly participates in the project. Organization Members have privileges in both project repositories and elections, and as such are expected to act in the interests of the whole project. An Organization Member must meet the responsibilities and has the requirements of a Contributor, plus: -* Responsibilities include: - * Continues to contribute regularly - * Help uphold our commmunity values and welcome newcomers -* Requirements: - * Enabled [two-factor - authentication](https://help.github.com/articles/about-two-factor-authentication) - on their GitHub account - * Have made multiple contributions to the project or community. Contributions - may include, but is not limited to: - * Authoring or reviewing PRs on GitHub - * Filing or commenting on issues on GitHub - * Contributing to subprojects, or community discussions (e.g. meetings, - chat, email, and discussion forums) - * [Joined the Slack channel](https://cloud-native.slack.com/archives/C0344AANLA1) - * [Get an invite to join CNCF](http://slack.cncf.io/) - * Have read the [contributor - guide](https://github.com/open-feature/.github/blob/main/CONTRIBUTING.md) - * Actively contributing to 1 or more subprojects. -* Privileges: - * May be assigned Issues and Reviews - * May give commands to CI/CD automation - * Can recommend other contributors to become Org Members - +- Responsibilities include: + - Continues to contribute regularly + - Help uphold our community values and welcome newcomers +- Requirements: + - Enabled [two-factor + authentication](https://help.github.com/articles/about-two-factor-authentication) + on their GitHub account + - Have made multiple contributions to the project or community. Contributions + may include, but is not limited to: + - Authoring or reviewing PRs on GitHub + - Filing or commenting on issues on GitHub + - Contributing to subprojects, or community discussions (e.g. meetings, + chat, email, and discussion forums) + - [Joined the Slack channel](https://cloud-native.slack.com/archives/C0344AANLA1) + - [Get an invite to join CNCF](http://slack.cncf.io/) + - Have read the [contributor + guide](https://github.com/open-feature/.github/blob/main/CONTRIBUTING.md) + - Actively contributing to 1 or more subprojects. +- Privileges: + - May be assigned Issues and Reviews + - May give commands to CI/CD automation + - Can recommend other contributors to become Org Members + The process for a Contributor to become an Organization Member is as follows: - 1. Sponsored by 2 [Approver](#approver). Note the following requirements for sponsors: - * Sponsors must have close interactions with the prospective member - e.g. - code/design/proposal review, coordinating on issues, etc. - * Sponsors must be approvers or maintainers in at least 1 CODEOWNERS file - in any repo in the OpenFeature org. - * Sponsors must be from multiple member companies to demonstrate integration - across community. - 2. [Open an issue](https://github.com/open-feature/community/issues/new) - * Ensure your sponsors are `@mentioned` on the issue - * Complete every item on the checklist ([preview the current version of the - template](https://github.com/open-feature/community/ISSUE_TEMPLATE/membership.md)) - * Make sure that the list of contributions included is representative of your - work on the project. - 3. Have your sponsoring reviewers reply confirmation of sponsorship: `I support` - 4. Once your sponsors have responded, your request will be reviewed by the - Technical Committee (TC). Any TC member can review the requirements and add - Members to the GitHub org. - - -### Triager +1. Sponsored by 2 [Approver](#approver). Note the following requirements for sponsors: + - Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc. + - Sponsors must be in an approvers or maintainers team for at least one resource in the[Community Configuration](https://github.com/open-feature/community/config/). + - Sponsors must be from multiple member companies to demonstrate integration across community. +1. [Open an issue](https://github.com/open-feature/community/issues/new) + + - Ensure your sponsors are `@mentioned` on the issue + - Complete every item on the checklist ([preview the current version of the + template](https://github.com/open-feature/community/issues/new?labels=membership&template=membership.md)) + - Make sure that the list of contributions included is representative of your + work on the project. + +1. Have your sponsoring reviewers reply confirmation of sponsorship: `I support` +1. Once your sponsors have responded, your request will be reviewed by the + Technical Committee (TC). Any TC member can review the requirements and add + Members to the GitHub org. + +## Triager + Triagers assist the maintainers and approvers with project management and backlog organization. The specific workflows and triage requirements depend on the project, and are set by the project maintainers. Defined by: [Triage permissions](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level), -with the names of the current Triagers commited to git, either in CONTRIBUTING, +with the names of the current Triagers committed to git, either in CONTRIBUTING, CODEOWNERS, or the bottom of the README. Triagers may be code contributors, but writing code is not a requirement for becoming a triager. Triagers are encouraged to be active participants in project meetings, chat rooms, and other discussion forums. -* Requirements +- Requirements -- Nominated by a maintainer, with no objections from other maintainers. -- Consistently attend meetings and interact with issues. + - Nominated by a maintainer, with no objections from other maintainers. + - Consistently contribute in meetings or in issues, PRs or discussions. -* Responsibilities and privileges +- Responsibilities and privileges -- Have an understanding of the goals and workflows defined by the maintainers. -- Respond to new PRs and Issues by asking clarifying questions. -- Organize the backlog by applying labels, milestones, assignees, and projects. + - Have an understanding of the goals and workflows defined by the maintainers. + - Respond to new PRs and Issues by asking clarifying questions. + - Organize the backlog by applying labels, milestones, assignees, and projects. +The process of becoming a Triager is: -The process of becoming a Trager is: - - 1. The contributor is nominated by opening a PR against the appropriate repository, which adds their GitHub username to the respective GitHub team for one or more directories. - 2. At least two members of the team that owns that repository or main directory, who are already Approvers, approve the PR. +1. The contributor is nominated by opening a PR against the appropriate repository, which adds their GitHub username to the respective GitHub team for one or more directories. +1. At least two members of the team that owns that repository or main directory, who are already Approvers, approve the PR. ## Approver @@ -149,87 +128,91 @@ focused on holistic acceptance of a contribution including: backwards/forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, etc. -Defined by: [CODEOWNERS -workflow](https://help.github.com/en/articles/about-code-owners). +- Defined by: + + - [CODEOWNERS workflow](https://help.github.com/en/articles/about-code-owners) + - [Community Configuration](https://github.com/open-feature/community/tree/main/config/open-feature) Approver status can be scoped to a part of the codebase. For example, critical core components may have higher bar for becoming an approver. -* Requirements +- Requirements -The following apply to the part of the codebase for which one would be an -approver in the `CODEOWNERS` files. + The following apply to the part of the codebase for which one would be an + approver in the `CODEOWNERS` files. - * Reviewer of the codebase for at least 1 month - * Reviewer for or author of PRs to the codebase, - with the definition of substantial subject to the maintainer's discretion - (e.g. refactors/adds new functionality rather than one-line pulls). - * Nominated by a maintainer - * With no objections from other maintainers - * Done through PR to update the `CODEOWNERS`. + - Reviewer of the codebase for at least 1 month + - Reviewer for or author of PRs to the codebase, + with the definition of substantial subject to the maintainer's discretion + (e.g. refactors/adds new functionality rather than one-line pulls). + - Nominated by a maintainer + - With no objections from other maintainers + - Done through PR to update the [Community Configuration](https://github.com/open-feature/community/tree/main/config/open-feature). -* Responsibilities and privileges +- Responsibilities and privileges -The following apply to the part of the codebase for which one would be an -approver in the `CODEOWNERS` files. + The following apply to the part of the codebase for which one would be an approver in the `CODEOWNERS` files. - * Approver status may be a precondition to accepting large code contributions - * Demonstrate sound technical judgement (may be asked to step down by a maintainer if they lose confidence of the maintainers) - * Responsible for project quality control via code reviews - * Focus on holistic acceptance of contribution such as dependencies with other - features, backwards / forwards compatibility, API and flag definitions, etc - * Expected to be responsive to review requests (inactivity for more than 1 month may result in suspension until active again) - * Mentor contributors and reviewers - * May approve code contributions for acceptance + - Approver status may be a precondition to accepting large code contributions + - Demonstrate sound technical judgement (may be asked to step down by a maintainer if they lose confidence of the maintainers) + - Responsible for project quality control via code reviews + - Focus on holistic acceptance of contribution such as dependencies with other + features, backwards / forwards compatibility, API and flag definitions, etc + - Expected to be responsive to review requests (inactivity for more than 1 month may result in suspension until active again) + - Mentor contributors and reviewers + - May approve code contributions for acceptance -### Maintainer +## Maintainer Maintainers are the technical authority for a subproject in the OpenFeature -project. They *MUST* have demonstrated both good judgement and responsibility -towards the health of that subproject. Maintainers *MUST* set technical +project. They _MUST_ have demonstrated both good judgement and responsibility +towards the health of that subproject. Maintainers _MUST_ set technical direction and make or approve design decisions for their subproject - either directly or through delegation of these responsibilities. -Defined by: GitHub organization ownership, permissions and entry in `CODEOWNERS` -files. - -* Requirements - -Unlike the roles outlined above, the maintainers of a subproject are typically -limited to a relatively small group of decision makers and updated as fits -the needs of the subproject. - -The following apply to the subproject for which one would be a maintainer. - * Deep understanding of the technical goals and direction of the subproject - * Deep understanding of the technical domain (specifically the language) of the - subproject - * Sustained contributions to design and direction by doing all of: - * Authoring and reviewing proposals - * Initiating, contributing and resolving discussions (emails, GitHub issues, - meetings) - * Identifying subtle or complex issues in designs and implementation PRs - * Directly contributed to the subproject through implementation and / or review - * Aligning with the overall project goals, specifications and design principles - defined by Technical Committee (TC). Bringing general questions and requests - to the discussions as part of specifications project. - -* Responsibilities and privileges - -The following apply to the subproject for which one would be a maintainer. - - * Make and approve technical design decisions for the subproject. - * Set technical direction and priorities for the subproject. - * Define milestones and releases. - * Decides on when PRs are merged to control the release scope. - * Mentor and guide approvers, reviewers, and contributors to the subproject. - * Escalate *reviewer* and *maintainer* workflow concerns (i.e. responsiveness, - availability, and general contributor community health) to the TC. - * Ensure continued health of subproject: - * Adequate test coverage to confidently release - * Tests are passing reliably (i.e. not flaky) and are fixed when they fail - * Ensure a healthy process for discussion and decision making is in place. - * Work with other maintainers to maintain the project's overall health and - success holistically. +- Defined by: + + - [Community Configuration](https://github.com/open-feature/community/config/) + - [CODEOWNERS workflow](https://help.github.com/en/articles/about-code-owners) + +- Requirements + + Unlike the roles outlined above, the maintainers of a subproject are typically + limited to a relatively small group of decision makers and updated as fits + the needs of the subproject. + + The following apply to the subproject for which one would be a maintainer. + + - Deep understanding of the technical goals and direction of the subproject + - Deep understanding of the technical domain (specifically the language) of the + subproject + - Sustained contributions to design and direction by doing all of: + - Authoring and reviewing proposals + - Initiating, contributing and resolving discussions (emails, GitHub issues, + meetings) + - Identifying subtle or complex issues in designs and implementation PRs + - Directly contributed to the subproject through implementation and / or review + - Aligning with the overall project goals, specifications and design principles + defined by Technical Committee (TC). Bringing general questions and requests + to the discussions as part of specifications project. + +- Responsibilities and privileges + + The following apply to the subproject for which one would be a maintainer. + + - Make and approve technical design decisions for the subproject. + - Set technical direction and priorities for the subproject. + - Define milestones and releases. + - Decides on when PRs are merged to control the release scope. + - Mentor and guide approvers, reviewers, and contributors to the subproject. + - Escalate _reviewer_ and _maintainer_ workflow concerns (i.e. responsiveness, + availability, and general contributor community health) to the TC. + - Ensure continued health of subproject: + - Adequate test coverage to confidently release + - Tests are passing reliably (i.e. not flaky) and are fixed when they fail + - Ensure a healthy process for discussion and decision making is in place. + - Work with other maintainers to maintain the project's overall health and + success holistically. ### Becoming a Maintainer @@ -239,15 +222,15 @@ The vote is officially started when a pull request to add a new maintainer is opened, and ends when the pull request is merged. The pull request may be merged when the following conditions are met: -* The person being nominated has accepted the nomination by approving the pull request -* All maintainers have approved the pull request OR a majority of maintainers +- The person being nominated has accepted the nomination by approving the pull request +- All maintainers have approved the pull request OR a majority of maintainers have approved the pull request and no maintainer has objected by requesting changes on the pull request. In the case that all maintainers have not given approval, the pull request should stay open for a minimum of 5 days before merging. The nominee is considered a maintainer after the pull request is merged. -#### Self-nomination is encouraged +### Self-nomination is encouraged If you feel like you meet the requirements above and are willing to take on the additional responsibilities and privileges of being a maintainer, it is @@ -262,19 +245,19 @@ in order to improve your chances to become a maintainer in the future. Process of becoming a maintainer: 1. Any current Maintainer may nominate a current Reviewer to become a new Maintainer, by opening a PR against the respective repository (Spec, java-sdk, community..) adding the nominee as an Approver in the respective maintainer group. -2. The nominee will add a comment to the PR testifying that they agree to all requirements of becoming a Maintainer. -3. A majority of the current Maintainers must then approve the PR. - +1. The nominee will add a comment to the PR testifying that they agree to all requirements of becoming a Maintainer. +1. A majority of the current Maintainers must then approve the PR. ## Inactivity + It is important for contributors to be and stay active to set an example and show commitment to the project. Inactivity is harmful to the project as it may lead to unexpected delays, contributor attrition, and a lost of trust in the project. -* Inactivity is measured by: - * Periods of no contributions for longer than 3 months - * Periods of no communication for longer than 3 months -* Consequences of being inactive include: - * Involuntary removal or demotion - * Being asked to move to Emeritus status +- Inactivity is measured by: + - Periods of no contributions for longer than 3 months + - Periods of no communication for longer than 3 months +- Consequences of being inactive include: + - Involuntary removal or demotion + - Being asked to move to Emeritus status ## Involuntary Removal or Demotion @@ -283,10 +266,13 @@ Involuntary removal/demotion of a contributor happens when responsibilities and Involuntary removal or demotion is handled through a vote by a majority of the current Maintainers. ## Stepping Down/Emeritus Process + If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project). Contact the Maintainers about changing to Emeritus status, or reducing your contributor level. +When a contributor returns to being more active, they may be promoted back to their previous position at the discretion of the current maintainers by opening a PR. If the current maintainers do not agree on restoring the previous responsibilities they should follow the contributor ladder steps. ## Contact -* For inquiries, please reach out to: - * members of the Governance Board + +- For inquiries, please reach out to: + - members of the Governance Board diff --git a/Elections/2023/Candidates.md b/Elections/2023/Candidates.md new file mode 100644 index 00000000..585aebd1 --- /dev/null +++ b/Elections/2023/Candidates.md @@ -0,0 +1,66 @@ +# 2023 OpenFeature Governance Committee Candidates + +In December 2023 we will hold the first election with 4 positions to be elected from the current Governance committee and 3 members from the community. +The 4 members that are elected from the current governance board will have a one year term and the 3 elected from the community will have a two year term. + +## Current Governance committee members (4 seats open, with 1 year term) + +- [Ben Rometsch](https://github.com/dabeeeenster), Flagsmith (Looking to continue board membership in 2024) +- [Justin Abrahms](https://github.com/justinabrahms), eBay +- [Michael Beemer](https://github.com/beeme1mr), Dynatrace (Looking to continue board membership in 2024) +- [Pete Hodgson](https://github.com/moredip), Independent (Looking to continue board membership in 2024) +- [Alex Jones](https://github.com/AlexsJones), AWS (Looking to continue board membership in 2024) +- [Alois Reitbauer](https://github.com/AloisReitbauer). Dynatrace (Looking to continue board membership in 2024) + +## List of new candidates (3 seats open, with 2 year term) + +In alphabetical order: + +### David Hirsch +- Company: Dynatrace +- GitHub: [DavidPHirsch](https://github.com/DavidPHirsch) +- Description: Open Source Program manager at Dynatrace and maintainer for Keptn, and for the OpenFeature community Repository, also a CNCF Ambassador. Driver for the Incubation Proposal and the participation of the Project in CNCF events. + +### Johan Rydberg +- Company: Spotify +- GitHub: [jrydberg](https://github.com/jrydberg) +- Description: General Manager for Experimentation at Spotify. Led the teams building the internal experimentation platform at Spotify, and most recently leading the efforts around Confidence, the commercial incarnation of Spotify's experimentation platform. + +### Jonathan Norris +- Company: DevCycle +- GitHub: [jonathannorris](https://github.com/jonathannorris) +- Description: Co-Founder & CTO @ DevCycle + Taplytics. I've built products in the A/B Testing + Feature Flagging space for over ten years across Taplytics and DevCycle. I've become a strong believer in the OpenFeature project over the last year, and look forward to helping support the future of the project. I hope to bring our experience working with large customers building with Feature Flags across both Client and Server-side use-cases. + +### Konrad Niemiec +- Company: Lekko +- GitHub: [konradjniemiec](https://github.com/konradjniemiec) +- Description: Founder & CEO @ Lekko. I've built dev tools for many years and have been exposed to many feature flagging and dynamic configuration tools at many organization. I am really excited to have contributed some big tech ideas over the last few year, and hope to contribute to OpenFeature by making it truly open. I hope to have measurable contributions in migration tooling, common code generaiton, and best practices for SDKs and other tools just getting started in feature flagging. + +### Kamil Nowosad +- Company: Google +- GitHub: [kamil-nowosad](https://github.com/kamil-nowosad) +- Description: Software Engineer at Google working on feature flags and experiments. I'm interested in growing popularity of OpenFeature and feature flags technology in general. I strongly support development of open standards around OpenFeature such as: Remote Flag Evaluation Protocol, Flag Definition Language (low-level machine-optimized and/or high-level human-optimized), config validations / policy checking (incl. static analysis) and telemetry. + +### Weyert de Boer +- Company: FNZ +- GitHub: [weyert](https://github.com/weyert) +- Description: Working on the API Ecosystem team, an end-user of OpenFeature, full supporter of the project, and love to help support to share an end-users point of view and experience, helped improve the OpenSLO standard. + +---------------------------- + +### Drew Gorton - WITHDRAWN +- Company: Unleash +- GitHub: [dgorton](https://github.com/dgorton) +- Description: Developer Relations leader and current head of DevRel for Unleash. I've helped organize and lead Open Source communities for 15+ years. Built a successful developer tool SaaS, and helped several small open-source developer platforms grow in adoption and scale. I believe that feature flags are an emergent engineering best practice, and I would like to support the adoption of open-source, cross-platform standards. + +### Janek Łukaszewicz - WITHDRAWN +- Company: Google +- GitHub: [oxddr](https://github.com/oxddr) +- Description: Working on Google-internal platform for feature flagging and A/B testing. Interested in OpenFeature from the perspective of the end-used that happen to be a large enterprise. I have an experience working with large-scale backend services and building a feature flag solution for them. I believe feature flags are simple and effective mean to improve software reliability and thus I strongly believe in OpenFeature initiative. + + diff --git a/Elections/2023/Election-Guidelines.md b/Elections/2023/Election-Guidelines.md new file mode 100644 index 00000000..2ca817a7 --- /dev/null +++ b/Elections/2023/Election-Guidelines.md @@ -0,0 +1,78 @@ +# OpenFeature 2023 Governance Committee election + +Please see **[the list of candidates running in the election here](https://github.com/open-feature/community/blob/main/Elections/2023/Candidates.md)**. + +This election should fill seven seats: +- four seats from the existing governance committee +- three seats from new candidates. + +Election schedule: + +* November 6th - December 6th 2023 - period to submit nominations +* December 7th 2023 - official nominees list published +* December 8th - January 31st 2024 - voting period +* February 1st 2024 - results announced + +We highly encourage participation in this election cycle to ensure that the community is well-represented by the Governance Committee. + +# TL;DR + +* If you've been nominated or are willing to nominate yourself: express your interest in [this issue](https://github.com/open-feature/community/issues/262) +* Vote between 8 December 2023 00:00 UTC and 31 January 2024 23:59 UTC via the [voting link](https://vote.heliosvoting.org/helios/elections/765b99df-f00a-4bd5-a885-f014e0f6d625/view) + +# Vacancies +This election should fill seven seats: +- fours seats from the existing governance committee +- three seats from new candidates +To encourage diversity there will be a maximum of one-third representation on the Governance Committee from any one company at any time. +If the outcomes of an election result in greater than 1/3 representation (or maximum of two, whichever is greater), the lowest vote getters from any particular company will be removed until representation on the committee is equal or less than one-third. + + +# Voting process + +Anyone can track the 2023 election process via [this GitHub issue](https://github.com/open-feature/community/issues/262). +We will ensure that all documents and assets related to the 2023 election process are public. + +For the 2023 elections, [Helios Voting](https://vote.heliosvoting.org/) was chosen as it's a hosted solution with cryptographic guarantees that no GC members can meddle with the results. + +Helios voting also allows us to add GitHub handles to the list of voters in addition to email addresses. +We need this, as we count contributions based on GitHub contributions and do not always have the contributor's email address. +The disadvantage of Helios is that it does not support ranked voting. + +# Nominations + +Anybody is eligible to run for the Governance Committee. During the "call for nomination" period, people can be nominated or nominate themselves by expressing their interest in [this issue](https://github.com/open-feature/community/issues/262) a Pull Request adding said candidate to the [candidates-2023.md](https://github.com/open-feature/community/blob/main/Elections/2023/Candidates.md) file in the OpenFeature community repository. + +The template in that file includes the following columns: + +* Full name +* GitHub alias +* Company affiliation (if applicable) +* Short bio or reasoning to join the Governance Committee (no more than a short paragraph) +* _Optional_: photo/picture of a nominee + +The Pull Request will not be merged until the candidate has confirmed their desire to be nominated (if not self-nominating) and ratified via PR comments. + +# Voter Eligibility + +All members of the OpenFeature Organization Members, Approvers, Maintainers will automatically be eligible to vote. + +# Vote + +Everyone with voting rights may log into [Helios Voting](https://vote.heliosvoting.org/helios/elections/765b99df-f00a-4bd5-a885-f014e0f6d625/view) using their GitHub account. +Voting will be approval voting, where each voter may select up to seven candidates, **four** from the current Governance Committee and three from the new nominees. +The seven candidates (four from current GC and three from new nominees) with the most votes win the election. +The winners should be from different organizations(at most 1/3 from the same organization), therefore only the 2 highest ranked nominees from each organization will be elected. +If the outcomes of an election result in greater than 1/3 representation (or maximum of two, whichever is greater), the lowest vote getters from any particular company will be removed until representation on the committee is equal or less than one-third. + +If there is a draw between the lower ranked candidates, there will be a runoff election between the tied candidates. +The runoff election will be held within 48 hours of the original election. +The runoff election will be a simple majority vote, and the candidate with the most votes will be elected. + +Per Helios, voting is entirely private: nobody will know any individual's vote. + +# Results + +Voting will close on the 31st January 2024 23:59 UTC. Nominees will be stack ranked. +If a nominee becomes ineligible, the election committee will skip those nominees and pick the nominee with the next-highest score. +The exact scores for each candidate will be public. diff --git a/LICENSE b/LICENSE.md similarity index 100% rename from LICENSE rename to LICENSE.md diff --git a/MAINTAINERS.md b/MAINTAINERS.md deleted file mode 100644 index 4ff063f4..00000000 --- a/MAINTAINERS.md +++ /dev/null @@ -1,19 +0,0 @@ -# OpenFeature maintainers - -This is an official list of OpenFeature maintainers and other key roles -with admin/maintain/write/triage permissions in the GitHub organizations. -The roles, their responsibilities and the ladder are documented in the [Governance Document](./README.md). - - - -## Maintainers - -* Michael Beemer, @beeme1mr, Dynatrace -* Alois Reitbauer, @AloisReitbauer, Dynatrace/CNCF/Keptn -* Oleg Nenashev, @oleg-nenashev, Dynatrace/CDF/Jenkins/Keptn -* David Hirsch @DavidPHirsch, Dynatrace/Keptn/TODO Group - -GitHub team: `@open-feature/maintainers` diff --git a/Makefile b/Makefile new file mode 100644 index 00000000..35af49ba --- /dev/null +++ b/Makefile @@ -0,0 +1,6 @@ + +.PHONY: peribolos + +peribolos: + docker run --rm -t -v $(CURDIR):/this -w /this/tools golang go run peribolosbuilder.go -config=../config + diff --git a/README.md b/README.md index efb00d89..afaf7975 100644 --- a/README.md +++ b/README.md @@ -1,46 +1,53 @@ -# OpenFeature Community Content +# OpenFeature Community
Table of Contents -* [Getting Involved](#getting-involved) -* [Governing Bodies](#governing-bodies) -* [Areas of Interest](#areas-of-interest) -* [Communication](#communication) - * [Discussions](#discussions) - * [Calendar](#calendar) - * [Social Media](social-media) -* [Roadmap](#roadmap) -* [License](#license) -* [Logos and Brand Guide](#logos-and-brand-guide) -* [Special Interest Groups](#special-interest-groups) -* [Contributing](#contributing) - * [Contributing Prerequisites (DCO)](#contributing-prerequisites) -* [Associated Components and Implementations](#associated-components-and-implementations) -* [Adopters](#adopters) -* [Code of Conduct](#code-of-conduct) +- [Getting Involved](#getting-involved) +- [Contributing](#contributing) + - [Contributing Prerequisites (DCO)](#contributing-prerequisites-dco) +- [Governing Bodies](#governing-bodies) + - [Interested Parties](#interested-parties) +- [Communication](#communication) + - [Discussions](#discussions) + - [Community Meetings](#community-meetings) + - [Social Media](#social-media) + - [Mailing List](#mailing-list) +- [Roadmap](#roadmap) +- [License](#license) +- [Logos and Brand Guide](#logos-and-brand-guide) +- [Special Interest Groups](#special-interest-groups) +- [Associated Components and Implementations](#associated-components-and-implementations) +- [Adopters](#adopters) +- [Code of Conduct](#code-of-conduct)
-## Getting involved +## Getting Involved -If you are interested to be informed about the project or to contribute, feel free to add yourself and/or your organization to [Interested Parties](./interested-parties.md). +If you are interested in being informed about the project or contributing, feel free to add yourself and/or your organization to [Interested Parties](./interested-parties.md). +## Contributing -## Governing Bodies +All contributors are welcome! +Please see the contributing guidelines +[here](https://github.com/open-feature/.github/blob/main/CONTRIBUTING.md). + +### Contributing Prerequisites (DCO) -* Governance Commitee (GC): [Charter](./governance-charter.md), [Members](./community-members.md#governance-board) -* Technical Committee (TC): [Charter](./tech-committee-charter.md), [Members](./community-members.md#technical-committee) +The [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/) requires all pull requests to be signed off using [Developer Certificate of Origin (DCO)](https://wiki.linuxfoundation.org/dco). +By submitting pull requests, submitters acknowledge they grant the [Apache License v2](./LICENSE) to the code and are eligible to grant this license for all commits submitted in their pull requests. -## Areas of Interest +## Governing Bodies -Technical committee members, maintainers, and approvers are encouraged to list their areas of interest in this [document](https://github.com/open-feature/community/blob/main/areas-of-interest.md) to help community members find interested parties and form new special interest groups. +- Governance Committee (GC): [Charter](./governance-charter.md), [Members](./community-members.md#governance-board) +- Technical Committee (TC): [Charter](./tech-committee-charter.md), [Members](./community-members.md#technical-committee) ### Interested Parties -If you are interested to be informed about the project or to contribute, feel free to add yourself and/or your organization to [Interested Parties](./interested-parties.md). +If you are interested in being informed about the project or contributing, feel free to add yourself and/or your organization to [Interested Parties](./interested-parties.md). ## Communication @@ -48,22 +55,26 @@ If you are interested to be informed about the project or to contribute, feel fr For those who are brand new to OpenFeature and want to chat or get redirected to the appropriate place for a specific question, feel free to join [the CNCF OpenFeature Slack channel](https://cloud-native.slack.com/archives/C0344AANLA1). If you are new, you can create a CNCF Slack account [here](https://slack.cncf.io/). -### Calendar +### Community Meetings -The community calendar contains all the upcoming OpenFeature meetings and events. You can access it via: +| Name | Meeting Time | Meeting Notes | Discussions | +| ---- | ------------ | ------------- | ----------- | +| OpenFeature Community Meeting | Every other Thursday at 10:00 am ET | [Google Doc](https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit?usp=sharing) | [Zoom](https://zoom-lfx.platform.linuxfoundation.org/meeting/96167755909?password=212f416d-85a3-4f2f-ad15-2d7d4ca43578) | -- [Web](https://calendar.google.com/calendar/embed?src=0ua7i1hiv5dh18b27toah63644%40group.calendar.google.com) -- [Google - Calendar](https://calendar.google.com/calendar/u/0?cid=MHVhN2kxaGl2NWRoMThiMjd0b2FoNjM2NDRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ) -- [iCal](https://calendar.google.com/calendar/ical/0ua7i1hiv5dh18b27toah63644%40group.calendar.google.com/public/basic.ics) +All upcoming OpenFeature meetings and events are on our [public calendar](https://zoom-lfx.platform.linuxfoundation.org/meetings/openfeature?view=week). -### Social Media +### Social Media -Follow-us on social media and help us to spread the word! +Follow us on social media and help us to spread the word! Please use the `#openfeature` hashtag or mention our accounts when you share the content. - Twitter: [@openfeature](https://twitter.com/openfeature) - LinkedIn: [OpenFeature](https://www.linkedin.com/company/openfeature/) +- YouTube: [OpenFeature](https://youtube.com/@openfeature/) + +### Mailing List + +Join our (low-traffic) [CNCF mailing list](https://lists.cncf.io/g/cncf-openfeature-project) to stay up to date on announcements, discussions, and more. ## Roadmap @@ -76,8 +87,7 @@ All OpenFeature projects are shipped under the permissive [Apache License v2](./ ## Logos and Brand Guide -The OpenFeature logos and brand guide can be found in the [CNCF artwork repository](https://github.com/cncf/artwork/tree/master/projects/openfeature). - +The OpenFeature logos and brand guide can be found in the [branding guidelines](./branding-guidelines.md). ## Special Interest Groups @@ -87,31 +97,15 @@ Notes and recordings from previous meetings can be found below: - [Meeting notes](https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit?usp=sharing) - [Recordings](https://www.youtube.com/channel/UCXSFt-dT2HORGXz1-ksxtxw) - -| Name | Meeting Time | Meeting Notes | Discussions | -| ---- | ------------ | ------------- | ----------- | -| | | | | - - -## Contributing - -All contributors are welcome! -Please see the contributing guidelines -[here](https://github.com/open-feature/.github/blob/main/CONTRIBUTING.md). - -### Contributing Prerequisites (DCO) - -The [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/) requires all pull requests are signed off using [Developer Certificate of Origin (DCO)](https://wiki.linuxfoundation.org/dco). -By submitting pull requests, submitters acknowledge they grant the [Apache License v2](./LICENSE) to the code and that they are eligible to grant this license for all commits submitted in their pull requests. +- [CNCF Hosted Project Community Chapter](https://community.cncf.io/openfeature/) ## Associated Components and Implementations -The OpenFeature specification defines abstractions and interfaces for the purposes of flexibly integrating with various feature flag management systems, as well as with tools related to feature flag evaluation (such as telemetry and logging). In order to maintain [neutrality and no/low dependencies](https://github.com/open-feature/spec#design-principles), implementations of these abstractions should not be included in SDKs. Such implementations may exist in the "contribs" repository for their respective language (ie: https://github.com/open-feature/node-sdk-contrib) or in other repositories not owned by the OpenFeature organization. We recommend implementations be open source, but that's not a requirement. +The OpenFeature specification defines abstractions and interfaces for the purposes of flexibly integrating with various feature flag management systems, as well as with tools related to feature flag evaluation (such as telemetry and logging). In order to maintain [neutrality and no/low dependencies](https://github.com/open-feature/spec#design-principles), implementations of these abstractions should not be included in SDKs. Such implementations may exist in the "contribs" repository for their respective language (ie: https://github.com/open-feature/js-sdk-contrib) or in other repositories not owned by the OpenFeature organization. We recommend implementations be open source, but that's not a requirement. ## Adopters -Please refer to [Adopters list](https://github.com/open-feature/community/blob/main/ADOPTERS.md) - +Please refer to [Adopters list](./ADOPTERS.md) ## Code of Conduct @@ -121,5 +115,3 @@ The project and its community abide by [the Code of Conduct](https://github.com/ This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1, available [here](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html). - - diff --git a/SECURITY.md b/SECURITY.md index ea73c329..c1047969 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,20 +1,3 @@ # Security Policy -## Supported Versions - -As outlined by our [Repository requirements](https://github.com/open-feature/.github/blob/main/CONTRIBUTING.md#repository-requirements), OpenFeature artifacts adhere to semantic versioning and include meaningful change logs. The OpenFeature specification includes [Document status](https://github.com/open-feature/spec/tree/main/specification#document-statuses) definitions, which are used to indicate the stability level of each specification section. - -## Reporting a Vulnerability - -If you find something suspicious and want to report it, we'd really appreciate it! - -### Ways to report - -* Send a message to [ccncf-openfeature-maintainers@lists.cncf.io][mailing-list] -* If you can't send an email, either open an issue on GitHub with the description or open a pull request on GitHub with a reproducer and/or fix. We really prefer if you'd talk to us over email, though, as our repositories are public and we would like to give a heads up to our users before disclosing it publicly. - -## Vulnerability Policies - -OpenFeature uses Snyk and trivy vulnerability scans in order to make sure we minimize vulnerabilities in our dependencies and get notified of new vulnerabilities. - -There are many situations where a vulnerability does not affect a particular dependency because of how the vulnerable package is used. In that situation the package authors may choose to stay at the current version rather than bumping the dependency, leading to a warning in the vulnerability scans but no actual vulnerability. +See [security policy](https://github.com/open-feature/.github/blob/main/SECURITY.md) in [.github](https://github.com/open-feature/.github). diff --git a/VENDORS.md b/VENDORS.md new file mode 100644 index 00000000..d97eee89 --- /dev/null +++ b/VENDORS.md @@ -0,0 +1,9 @@ +# Vendors + +A non-exhaustive, alphabetized list of organizations that offer an OpenFeature Provider. + +| Company | Logo | Notes | +| ------------------------------------------------- | ---------- | :---: | +| | | | + +_Sorted alphabetically by name_ diff --git a/areas-of-interest.md b/areas-of-interest.md deleted file mode 100644 index ec87bf06..00000000 --- a/areas-of-interest.md +++ /dev/null @@ -1,64 +0,0 @@ -# Member areas of interest - -OpenFeature technical committee members, maintainers, and approvers -may list their areas of interest below, to help the community to find -good points of contact for topics of interest across the project. - -Technical committee members are required to list these areas of -interest, and this is optional for maintainers and approvers. These -listings may be useful to find an appropriate person to tag on an -issue, for example. - -Members who are specifically employed by a company to contribute to -the OpenFeature project are recommended to list their company -affiliation, so that they may be contacted with vendor-specific -concerns. - - - - - - - -## Technical committee members - -### [Dan O’Brien](https://github.com/InTheCloudDan), LaunchDarkly - -- -### [Todd Baert](https://github.com/toddbaert), Dynatrace - -- -### [Steve Arch](https://github.com/agentgonzo), CloudBees - -- - -## Maintainers and approvers - -Maintainers and approvers are invited to list their areas of interest -to further assist the community in finding appropriate points of -contact. - -### [Alois Reitbauer](https://github.com/aloisreitbauer), Dynatrace - -- -### [Ben Rometsch](https://github.com/dabeeeenster), Flagsmith - -- -### [Justin Abrahms](https://github.com/justinabrahms), eBay - -- -### [Alex Jones](https://github.com/AlexsJones), Canonical - -- -### [Michael Beemer](https://github.com/beeme1mr), Dynatrace - -- -### [Pete Hodgson](https://github.com/moredip), Independent - -- -### [David Hirsch](https://github.com/DavidPHirsch), Dynatrace - -- Community and Outreach -- Adoption - - diff --git a/branding-guidelines.md b/branding-guidelines.md index 76e071ea..82ed958a 100644 --- a/branding-guidelines.md +++ b/branding-guidelines.md @@ -1,4 +1,4 @@ -# OpenFeature Branding Guidelines +# Branding Guidelines ## Name @@ -8,24 +8,32 @@ OpenFeature should be stylized as pascal case (i.e. `OpenFeature`) when possible Various layouts and versions are available including: -- [Horizontal](assets/logo/horizontal) - - [Black](assets/logo/horizontal/black) - - [White](assets/logo/horizontal/white) -- [Stacked](assets/logo/stacked) - - [Black](assets/logo/stacked/black) - - [White](assets/logo/stacked/white) -- [Icon](assets/logo/icon) - - [Black](assets/logo/icon/black) - - [White](assets/logo/icon/white) +### SVG -### Colors +| | black | white | +| ---------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------- | +| Horizontal | ![svg](./assets/logo/horizontal/black/openfeature-horizontal-black.svg) | ![svg](./assets/logo/horizontal/white/openfeature-horizontal-white.svg) | +| Stacked | ![svg](./assets/logo/stacked/black/openfeature-stacked-black.svg) | ![svg](./assets/logo/stacked/white/openfeature-stacked-white.svg) | +| Icon | ![svg](./assets/logo/icon/black/openfeature-icon-black.svg) | ![svg](./assets/logo/icon/white/openfeature-icon-white.svg) | -| Image | Hex | -| --------------------------------------------------------------- | --------- | -| ![#231F20](https://via.placeholder.com/15/231F20/231F20.png) | `#231F20` | -| ![#787173](https://via.placeholder.com/15/787173/787173.png) | `#787173` | -| ![#FFFFFF](https://via.placeholder.com/15/FFFFFF/FFFFFF.png) | `#FFFFFF` | +### PNG -### Font +| | black | white | +| ---------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------- | +| Horizontal | ![png](./assets/logo/horizontal/black/openfeature-horizontal-black.png) | ![png](./assets/logo/horizontal/white/openfeature-horizontal-white.png) | +| Stacked | ![png](./assets/logo/stacked/black/openfeature-stacked-black.png) | ![png](./assets/logo/stacked/white/openfeature-stacked-white.png) | +| Icon | ![png](./assets/logo/icon/black/openfeature-icon-black.png) | ![png](./assets/logo/icon/white/openfeature-icon-white.png) | -The font used in the logo is [Poppins](https://fonts.google.com/specimen/Poppins) which is licensed under the [Open Font License](https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL). +## Colors + +| Color Name | Sample | Hex | +| ------------ | ------------------------------------------------------------ | --------- | +| Raisin Black | ![#231F20](https://via.placeholder.com/15/231F20/231F20.png) | `#231F20` | +| Sonic Silver | ![#787173](https://via.placeholder.com/15/787173/787173.png) | `#787173` | +| White | ![#FFFFFF](https://via.placeholder.com/15/FFFFFF/FFFFFF.png) | `#FFFFFF` | +| Purple | ![#5D5DFF](https://via.placeholder.com/15/5D5DFF/5D5DFF.png) | `#5D5DFF` | +| Green | ![#00c800](https://via.placeholder.com/15/00c800/00c800.png) | `#00c800` | + +## Font + +The font used in the logo is [Poppins](https://fonts.google.com/specimen/Poppins) and the stylized font on the website is [Architects Daughter](https://fonts.google.com/specimen/Architects+Daughter). Both fonts are licensed under the [Open Font License](https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL). diff --git a/community-members.md b/community-members.md index 74432485..14c6db12 100644 --- a/community-members.md +++ b/community-members.md @@ -1,48 +1,56 @@ -# OpenFeature Community Members +# Community Members ## Governance Board This is the current Governance Committee, per the Governance Committee Charter, in alphabetical order: -- [Alois Reitbauer](https://github.com/aloisreitbauer), Dynatrace, term: Oct 1st, 2022 - TBD -- [Ben Rometsch](https://github.com/dabeeeenster), Flagsmith, term: April 28, 2022 - TBD -- [Justin Abrahms](https://github.com/justinabrahms), eBay, term: April 28, 2022 - TBD -- [Michael Beemer](https://github.com/beeme1mr), Dynatrace, term: April 28, 2022 - TBD -- [Pete Hodgson](https://github.com/moredip), Independent, term: April 28, 2022 - TBD -- [Alex Jones](https://github.com/AlexsJones), Canonical, term: Nov 1, 2022 - TBD +- [Alois Reitbauer](https://github.com/aloisreitbauer), Dynatrace, term: February 1st, 2024 - January 31st 2025 +- [Ben Rometsch](https://github.com/dabeeeenster), Flagsmith, term: February 1st, 2024 - January 31st 2025 +- [Michael Beemer](https://github.com/beeme1mr), Dynatrace, term: February 1st, 2024 - January 31st 2025 +- [Pete Hodgson](https://github.com/moredip), Independent, term: February 1st, 2024 - January 31st 2025 +- [Johan Rydberg](https://github.com/jrydberg), Spotify, term: February 1st, 2024 - January 31st 2026 +- [Jonathan Norris](https://github.com/jonathannorris), DevCycle, term: February 1st, 2024 - January 31st 2026 +- [Weyert de Boer](https://github.com/weyert), FNZ, term: February 1st, 2024 - January 31st 2026 -currently there is one vacant seat - -> NOTE: -> In April 2022 _Project Maintainers_ assigned five seven individuals to be members of the _Bootstrap Governing Committee_. -> This is a **temporary** arrangement that should be replaced by an elected governing body before March 2024. -> Two seats remain vacant at the moment +The next election will take place in January 2025. ## Technical Committee This is the current Technical Committee, per the Technical Committee Charter, in alphabetical order: -- [Dan O’Brien](https://github.com/InTheCloudDan), LaunchDarkly, term: April 28, 2022 - April 28, 2023 -- [Todd Baert](https://github.com/toddbaert), Dynatrace, term: April 28, 2022 - April 28, 2023 -- [Steve Arch](https://github.com/agentgonzo), CloudBees, term: April 28, 2022 - April 28, 2023 +- [Lukas Reining](https://github.com/lukas-reining), [codecentric](https://www.codecentric.de/) +- [Ryan Lamb](https://github.com/kinyoklion), [LaunchDarkly](https://github.com/launchdarkly) +- [Thomas Poignant](https://github.com/thomaspoignant), [Adevinta](https://github.com/adevinta) +- [Todd Baert](https://github.com/toddbaert), [Dynatrace](https://github.com/Dynatrace) ## Community Management -These are community maintainers, responsible for cross-functional project communications, events, and other functions as needed. +These are community maintainers responsible for cross-functional project communications, events, and other functions as needed. + +- [Andrew MacLean](https://github.com/andrewdmaclean) DevCycle +- [David Hirsch](https://github.com/DavidPHirsch) Dynatrace + +### Project roles + +The following project roles are defined at the moment: +_Community Participant_, +_Contributor_, +_Organization Member_, +_Triager_, +_Approver_, +_Maintainer_, +_Technical Committee Member_, +_Bootstrap Governance Committee Member_, +_Emeritus_. + +See [Contributor Ladder](./CONTRIBUTOR_LADDER.md) for additional information. -[David Hirsch](https://github.com/DavidPHirsch) Dynatrace -## Specifications and Approvers -Members of the Technical Committee are the maintainers of OpenFeature spec -Spec Approvers: -## Java SDK -Repo: open-feature/java-sdk -The list of active members (both "approvers" and "maintainers") for the Java SDK can be found in the open-feature/java-sdk README file. diff --git a/config/README.md b/config/README.md new file mode 100644 index 00000000..057cfa39 --- /dev/null +++ b/config/README.md @@ -0,0 +1,169 @@ +# Community Configuration + +As handling permissions, assignments, etc. gets more and more complicated, the bigger a community gets, +we decided to opt-in for a GitOps approach for community management. + +We are using [Peribolos](https://docs.prow.k8s.io/docs/components/cli-tools/peribolos/) which is developed and maintained by Kubernetes. +They actively use it to manage their own communities, see [kubernetes/org](https://github.com/kubernetes/org). + +To reduce efforts and duplication we decided to adapt the generation approach to our needs. + +## Overview + +We are using our [community-tools](https://github.com/open-feature/community-tooling/) to generate a proper configuration based on our opinionated one for peribolos. + +It is also available as a docker image to be used locally: + +```console +docker run --rm -v $(pwd):/config ghcr.io/open-feature/community-tooling:v0 +``` + +## Configuration Structure + +Each directory within the `config` directory represents a GitHub Organization (therefore we will refrain from it as `org-folder`). +This directory will only be picked up when there is a `org.yaml` within the directory. + +Within this `org-folder` we can have multiple teams/workgroups. +Those teams are represented with their subfolder (the name of the team) containing a `workgroup.yaml`. + +The `community-tools` will fetch these configurations and generate a proper peribolos configuration based on this. + +### org.yaml + +The `org.yaml` follows the default peribolos configuration format. + +It will be used to: + +- define members and admins of the organization +- define default settings for the organization such as: + - members allowed to create repositories + - default permissions for members + - ... +- repositories and their configuration +- global teams + +#### special teams + +There are 3 special teams within the `org.yaml`. + +### <workgroup>/workgroup.yaml + +Each workgroup represents an organizational unit, which needs to work on the same repositories. + +A workgroup consists of following roles: + +- approvers (triage permission) +- maintainers (maintain permission) +- admins (admin permission) + +Based on the definition above a `workgroup.yaml` has the following structure: + +```yaml +repos: # a list of repositories the team has access to + - repo-1 + - repo-2 + +approvers: + - approver-1 + +maintainers: + - maintainer-1 + +admins: + - admins-1 +``` + +Repositories are not mutually exclusive to workgroups. +Hence, multiple workgroups can have access to the same repositories. + +> **Note** +> Use admins carefully and only when it is really needed. +> Admins can change secrets etc. + +Based on this configuration we will generate 3 teams: + +- <workgroup>-approvers +- <workgroup>-maintainers +- <workgroup>-admins + +Furthermore, we will assign those 3 teams also permissions for the defined repositories. + +#### Example + +Let's say we have a `workgroup.yaml` within `org-folder/workgroup`. + +The content is: + +```yaml +repos: + - repo-1 + +approvers: + - approver-1 + +maintainers: + - maintainer-1 + +admins: + - admins-1 +``` + +Following Teams will be generated, with the respective permissions for the repository `repo-1`: + +- workgroup-approvers: triage +- workgroup-maintainers: maintain +- workgroup-admins: admin + +## How to ... + +### ... add a member to the organization? + +Add them within the `org.yaml` of the GitHub Organization to the list of members. + +```yaml +members: + - +``` + +### ... generate a new workgroup? + +Generate a directory within the `org-folder` of the GitHub Organization with the team name. +Add a `workgroup.yaml` defining the repos, approvers, maintainers, and admins. + +```yaml +repos: + - repo-1 + +approvers: + - approver-1 + +maintainers: + - maintainer-1 + +admins: + - admins-1 +``` + +### ... set a member as emeritus? + +> **Warning** +> First discuss this with the community and the member you want to set to emeritus state. + +Remove the member from all `workgroup.yaml` files, and other teams within the `org.yaml`. + +If the user used to be an Admin of the organization moves them from `admins` to `members` in the `org.yaml`. + +Add the user to the emeritus-team definition within `org`.yaml` of the desired GitHub Organization. + +### ... create a new repository? + +Within the `org.yaml` of the designated organization, add an entry in the `repos` section. +As an example, we want to add a new repository called `peribolos-test`, we will add the following: + +```yaml +repos: + # ... + peribolos-test: + description: "my peribolos test" + # ... +``` diff --git a/config/open-feature/cloud-native/workgroup.yaml b/config/open-feature/cloud-native/workgroup.yaml new file mode 100644 index 00000000..efc92a35 --- /dev/null +++ b/config/open-feature/cloud-native/workgroup.yaml @@ -0,0 +1,27 @@ +repos: + - flagd + - flagd-schemas + - flagd-testbed + - open-feature-operator + +approvers: + - aepfli + - agardnerIT + - beeme1mr + - craigpastro + - justinabrahms + - odubajDT + - tcarrio + - thisthat + - thomaspoignant + + +maintainers: + - AlexsJones + - bacherfl + - james-milligan + - toddbaert + - kavindu-dodan + - skyerus + +admins: [] diff --git a/config/open-feature/education/workgroup.yaml b/config/open-feature/education/workgroup.yaml new file mode 100644 index 00000000..fa3e53d6 --- /dev/null +++ b/config/open-feature/education/workgroup.yaml @@ -0,0 +1,19 @@ +repos: + - docs.openfeature.dev + - openfeature.dev + - killercoda + - playground + - five-minutes-to-feature-flags + - cloud-native-demo + +approvers: + - justinabrahms + - andrewdmaclean + - beeme1mr + - toddbaert + - agardnerIT + - moredip + +maintainers: [] + +admins: [] diff --git a/config/open-feature/org.yaml b/config/open-feature/org.yaml new file mode 100644 index 00000000..eb9464d3 --- /dev/null +++ b/config/open-feature/org.yaml @@ -0,0 +1,337 @@ +# org settings +name: OpenFeature +description: Standardizing Feature Flagging for Everyone + +default_repository_permission: read + +has_organization_projects: true +has_repository_projects: true +members_can_create_repositories: false + +admins: + # org management bot + - openfeaturebot + + # governance board + - beeme1mr + - AloisReitbauer + - moredip + - dabeeeenster + - jrydberg + - jonathannorris + - weyert + + # technical steering committee + - lukas-reining + - kinyoklion + - toddbaert + - thomaspoignant + +# org member settings - keep alphabetical +# add yourself here if you're interested in being an org member! +members: + - ABC2015 + - adams85 + - aepfli + - agardnerIT + - agentgonzo + - ajhelsby + - ajwootto + - alemrtv + - alexandraoberaigner + - AlexsJones + - alina-v1 + - alxckn + - andrewdmaclean + - AnaisUrlichs + - anghelflorinm + - Arhell + - ARobertsCollibra + - askpt + - austindrenski + - bacherfl + - benjiro + - Billlynch + - c4milo + - Calibretto + - cdonnellytx + - chrfwow + - colebaileygit + - craigpastro + - cpitstick-latai + - davejohnston + - DavidPHirsch + - DBlanchard88 + - dgorton + - djosephsen + - dlopes7 + - dnsmichi + - dominikhaska + - dyladan + - ejscunha + - ericpattison + - fabriziodemaria + - faulkt + - federicobond + - gagantrivedi + - gruebel + - guidobrei + - hairyhenderson + - heckelmann + - hlipsig + - InTheCloudDan + - ivarconr + - jakedoublev + - james-milligan + - jamescarr + - jarebudev + - jenshenneberg + - josecolella + - juanparadox + - justaugustus + - justinabrahms + - kamil-nowosad + - Kavindu-Dodan + - kbychu + - laliconfigcat + - liran2000 + - lopitz + - luizbon + - luizgribeiro + - madhead + - markphelps + - matthewelwell + - maxveldink + - mfranberg + - mihirm21 + - miigwi + - mkorbi + - mowies + - mschoenlaub + - nicklasl + - nickybondarenko + - nikolasleblanc + - odubajDT + - oleg-nenashev + - Olunusib + - oxddr + - patricioe + - pradeepbbl + - rcrowe + - RealAnna + - rgrassian-split + - rschosser + - ryanprayogo + - s-sen + - sago2k8 + - salaboy + - sheepduke + - sighphyre + - sindhuinti + - skyerus + - ssharaev + - staceypotter + - tcarrio + - technicalpickles + - tegenterter + - therealmitchconnors + - thisthat + - thiyagu06 + - thschue + - tjosepo + - tomkerkhove + - UtkarshSharma2612 + - vahidlazio + - vpetrusevici + - warber + - wichopy + - znonthedev + - z4kn4fein + +teams: + emeritus: + members: + - oleg-nenashev + - thschue + + admins: + members: [] + + maintainers: + members: [] + + approvers: + members: [] + + Technical Steering Committee: + members: + - lukas-reining + - kinyoklion + - toddbaert + - thomaspoignant + + Governance Board: + members: + - beeme1mr + - AloisReitbauer + - AlexsJones + - moredip + - justinabrahms + - dabeeeenster + + Interested Parties: + description: Group for members of https://github.com/openfeatureflags/governance/blob/main/interested-parties.md + maintainers: + - justinabrahms + - AloisReitbauer + - beeme1mr + + members: + - miigwi + - weyert + - dabeeeenster + - markphelps + - salaboy + - dnsmichi + - justaugustus + - therealmitchconnors + - davejohnston + - AlexsJones + - dyladan + - benjiro + - tomkerkhove + - kinyoklion + - mkorbi + - thomaspoignant + - faulkt + - tegenterter + - AnaisUrlichs + - thschue + - james-milligan + privacy: closed + repos: + vendor-survey: write + +repos: + # Template for adding a new project + # mandatory: + # + # : + # description: + # + # optional: + # archived: - defaults to false + # private: - defaults to false + # has_issues: - defaults to true + # has_projects: - defaults to true + # has_wiki: - defaults to false + .github: + description: This repository stores various defaults for the GitHub organization + angular-test-app: + cli: + description: OpenFeature’s official command-line tool + cloud-native-demo: + description: A cloud-native feature flag demo, featuring multiple providers, telemetry, and a guided tour + community: + description: OpenFeature project community and governance + community-tooling: + description: Tools for Community Management + contribfest-eu-24: + dart-server-sdk: + demo-repository: + description: A code repository designed to show the best GitHub has to offer. + private: true + docs.openfeature.dev: + description: OpenFeature Documentation + has_projects: false + archived: true + dotnet-sdk: + description: .NET implementation of the OpenFeature SDK + dotnet-sdk-contrib: + description: OpenFeature Providers and Hooks for .NET + elixir-sdk: + description: Elixir SDK for OpenFeature + five-minutes-to-feature-flags: + description: A short introduction to the core concepts of OpenFeature + flagd: + description: A feature flag daemon with a Unix philosophy + flagd-testbed: + description: Shared test harness for flagd SDK testing, with Gherkin tests + flagd-schemas: + description: Schemas and spec files pertaining to flagd + homepage: https://buf.build/open-feature/flagd + go-sdk: + description: Go SDK for OpenFeature + go-sdk-contrib: + description: Community maintained OpenFeature Providers and Hooks for Go + homebrew-core: + description: "\U0001F37B Default formulae for the missing package manager + for macOS (or Linux)" + has_issues: false + homepage: https://brew.sh + java-sdk: + description: Java implementation of the OpenFeature SDK + java-sdk-contrib: + description: Community contributions for hooks and reference providers + js-sdk: + description: JavaScript SDK for OpenFeature + js-sdk-contrib: + description: OpenFeature Providers and Hooks for JavaScript + killercoda: + description: Killercoda Interactive Examples for OpenFeature + has_projects: false + kotlin-sdk: + description: Kotlin implementation of the OpenFeature SDK for Android clients + ofep: + description: A focal point for OpenFeature research, proposals and requests + for comments + has_projects: false + open-feature-operator: + description: A Kubernetes feature flag operator + open-feature.github.io: + archived: true + description: OpenFeature website + openfeature.dev: + description: OpenFeature Website + php-sdk: + description: PHP implementation of the OpenFeature SDK + has_projects: false + php-sdk-contrib: + description: OpenFeature Providers and Hooks for PHP + php-sdk-contrib-flagd-provider: + description: Flagd provider for the OpenFeature PHP SDK + private: true + playground: + description: OpenFeature SDK demos and experimentation + protocol: + description: OpenFeature Remote Evaluation Protocol + python-sdk: + description: Python SDK for OpenFeature + python-sdk-contrib: + description: Community contributions for hooks and reference providers in + python + ruby-sdk: + description: Ruby implementation of the OpenFeature SDK + react-native-test-app: + react-test-app: + description: Small test app for @openfeature/react-sdk development and e2e testing + ruby-sdk: + description: Ruby implementation of the OpenFeature SDK + ruby-sdk-contrib: + description: Community contributions for hooks and reference providers in Ruby + rust-sdk: + rust-sdk-contrib: + description: Community maintained OpenFeature Providers and Hooks for Rust + spec: + description: OpenFeature specification + swift-sdk: + description: Swift implementation of the OpenFeature SDK for iOS clients + toc-proposal: + description: TOC proposal fork + toggle-shop: + description: ToggleShop is a demo e-commerce app for showcasing OpenFeature + vendor-survey: + archived: true + private: true + watchman: + description: A Kubernetes admission controller driven by open-feature diff --git a/config/open-feature/org/workgroup.yaml b/config/open-feature/org/workgroup.yaml new file mode 100644 index 00000000..41e8fc2b --- /dev/null +++ b/config/open-feature/org/workgroup.yaml @@ -0,0 +1,44 @@ +repos: + - ofep + - community + - community-tooling + - .github + - spec + - toc-proposal + +# keep alphabetical +approvers: + - aepfli + - agentgonzo + - AlexsJones + - AloisReitbauer + - bacherfl + - beeme1mr + - benjiro + - dabeeeenster + - davejohnston + - fabriziodemaria + - federicobond + - InTheCloudDan + - james-milligan + - jonathannorris + - josecolella + - jrydberg + - justinabrahms + - Kavindu-Dodan + - kinyoklion + - lukas-reining + - maxveldink + - moredip + - nicklasl + - staceypotter + - tcarrio + - thiyagu06 + - thomaspoignant + - toddbaert + - weyert + +maintainers: + - DavidPHirsch + +admins: [] diff --git a/config/open-feature/sdk-dart/workgroup.yaml b/config/open-feature/sdk-dart/workgroup.yaml new file mode 100644 index 00000000..5fa9ef25 --- /dev/null +++ b/config/open-feature/sdk-dart/workgroup.yaml @@ -0,0 +1,9 @@ +repos: + - dart-server-sdk + +approvers: [] + +maintainers: + - ABC2015 + +admins: [] diff --git a/config/open-feature/sdk-dotnet/workgroup.yaml b/config/open-feature/sdk-dotnet/workgroup.yaml new file mode 100644 index 00000000..788b4886 --- /dev/null +++ b/config/open-feature/sdk-dotnet/workgroup.yaml @@ -0,0 +1,18 @@ +repos: + - dotnet-sdk + - dotnet-sdk-contrib + +approvers: + - bacherfl + - cdonnellytx + - askpt + - austindrenski + - jenshenneberg + +maintainers: + - beeme1mr + - toddbaert + - benjiro + - kinyoklion + +admins: [] diff --git a/config/open-feature/sdk-golang/workgroup.yaml b/config/open-feature/sdk-golang/workgroup.yaml new file mode 100644 index 00000000..489c18e9 --- /dev/null +++ b/config/open-feature/sdk-golang/workgroup.yaml @@ -0,0 +1,20 @@ +repos: + - go-sdk + - go-sdk-contrib + +approvers: + - beeme1mr + - agentgonzo + - thisthat + +maintainers: + - AlexsJones + - bacherfl + - davejohnston + - james-milligan + - Kavindu-Dodan + - skyerus + - thomaspoignant + - toddbaert + +admins: [] diff --git a/config/open-feature/sdk-java/workgroup.yaml b/config/open-feature/sdk-java/workgroup.yaml new file mode 100644 index 00000000..5e4de8ed --- /dev/null +++ b/config/open-feature/sdk-java/workgroup.yaml @@ -0,0 +1,19 @@ +repos: + - java-sdk + - java-sdk-contrib + +approvers: + - thiyagu06 + - thomaspoignant + - ajhelsby + - thisthat + - liran2000 + +maintainers: + - aepfli + - justinabrahms + - toddbaert + - agentgonzo + - kavindu-dodan + +admins: [] diff --git a/config/open-feature/sdk-javascript/workgroup.yaml b/config/open-feature/sdk-javascript/workgroup.yaml new file mode 100644 index 00000000..454721a8 --- /dev/null +++ b/config/open-feature/sdk-javascript/workgroup.yaml @@ -0,0 +1,19 @@ +repos: + - js-sdk + - js-sdk-contrib + - react-test-app + +approvers: + - aepfli + - weyert + - james-milligan + - tcarrio + - luizgribeiro + - jonathannorris + +maintainers: + - beeme1mr + - toddbaert + - lukas-reining + +admins: [] diff --git a/config/open-feature/sdk-kotlin/workgroup.yaml b/config/open-feature/sdk-kotlin/workgroup.yaml new file mode 100644 index 00000000..e9d83352 --- /dev/null +++ b/config/open-feature/sdk-kotlin/workgroup.yaml @@ -0,0 +1,13 @@ +repos: + - kotlin-sdk + +approvers: [] + +maintainers: + - fabriziodemaria + - nicklasl + - nickybondarenko + - toddbaert + - vahidlazio + +admins: [] diff --git a/config/open-feature/sdk-php/workgroup.yaml b/config/open-feature/sdk-php/workgroup.yaml new file mode 100644 index 00000000..cdb1c389 --- /dev/null +++ b/config/open-feature/sdk-php/workgroup.yaml @@ -0,0 +1,11 @@ + +repos: + - php-sdk + - php-sdk-contrib + +approvers: [] + +maintainers: + - tcarrio + +admins: [] diff --git a/config/open-feature/sdk-python/workgroup.yaml b/config/open-feature/sdk-python/workgroup.yaml new file mode 100644 index 00000000..01d67c9d --- /dev/null +++ b/config/open-feature/sdk-python/workgroup.yaml @@ -0,0 +1,17 @@ +repos: + - python-sdk + - python-sdk-contrib + +approvers: + - gruebel + +maintainers: + - federicobond + - hlipsig + - dabeeeenster + - mschoenlaub + - tcarrio + - matthewelwell + - ajhelsby + +admins: [] diff --git a/config/open-feature/sdk-ruby/workgroup.yaml b/config/open-feature/sdk-ruby/workgroup.yaml new file mode 100644 index 00000000..1ae7317d --- /dev/null +++ b/config/open-feature/sdk-ruby/workgroup.yaml @@ -0,0 +1,13 @@ + +repos: + - ruby-sdk + - ruby-sdk-contrib + +approvers: + - maxveldink + +maintainers: + - josecolella + - technicalpickles + +admins: [] diff --git a/config/open-feature/sdk-rust/workgroup.yaml b/config/open-feature/sdk-rust/workgroup.yaml new file mode 100644 index 00000000..b771b02e --- /dev/null +++ b/config/open-feature/sdk-rust/workgroup.yaml @@ -0,0 +1,12 @@ + +repos: + - rust-sdk + - rust-sdk-contrib + +approvers: [] + +maintainers: + - AlexsJones + - sheepduke + +admins: [] diff --git a/config/open-feature/sdk-swift/workgroup.yaml b/config/open-feature/sdk-swift/workgroup.yaml new file mode 100644 index 00000000..01a8fcd5 --- /dev/null +++ b/config/open-feature/sdk-swift/workgroup.yaml @@ -0,0 +1,16 @@ +repos: + - swift-sdk + +approvers: [] + +maintainers: + - alina-v1 + - Calibretto + - fabriziodemaria + - mfranberg + - toddbaert + - nicklasl + - nickybondarenko + - vahidlazio + +admins: [] diff --git a/config/open-feature/spec-definition/workgroup.yaml b/config/open-feature/spec-definition/workgroup.yaml new file mode 100644 index 00000000..7e053f8c --- /dev/null +++ b/config/open-feature/spec-definition/workgroup.yaml @@ -0,0 +1,14 @@ +repos: + +approvers: + +maintainers: + - thomaspoignant + - toddbaert + - Kavindu-Dodan + - moredip + - beeme1mr + - oxddr + - kamil-nowosad + +admins: [] diff --git a/config/open-feature/spec-evaluation/workgroup.yaml b/config/open-feature/spec-evaluation/workgroup.yaml new file mode 100644 index 00000000..4ba10cc6 --- /dev/null +++ b/config/open-feature/spec-evaluation/workgroup.yaml @@ -0,0 +1,17 @@ +repos: + - protocol + +approvers: + +maintainers: + - thomaspoignant + - toddbaert + - fabriziodemaria + - Kavindu-Dodan + - nicklasl + - oxddr + - kamil-nowosad + - jonathannorris + - lukas-reining + +admins: [] diff --git a/config/open-feature/tooling/workgroup.yaml b/config/open-feature/tooling/workgroup.yaml new file mode 100644 index 00000000..6c1a3d8e --- /dev/null +++ b/config/open-feature/tooling/workgroup.yaml @@ -0,0 +1,9 @@ +repos: + - community-tooling + +approvers: [] + +maintainers: + - aepfli + +admins: [] diff --git a/docusaurus-sidebar.js b/docusaurus-sidebar.js new file mode 100644 index 00000000..7af424a6 --- /dev/null +++ b/docusaurus-sidebar.js @@ -0,0 +1,68 @@ +// @ts-check + +/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ +const sidebarCommunity = { + community: [ + { + type: 'doc', + id: 'README', + label: 'Overview', + }, + + { + type: 'doc', + id: 'mission-vision', + }, + { + type: 'doc', + id: 'CONTRIBUTOR_LADDER', + }, + { + type: 'doc', + id: 'community-members', + label: 'Members', + }, + { + type: 'category', + label: 'Charters', + collapsible: false, + items: [ + { + type: 'doc', + id: 'governance-charter', + }, + { + type: 'doc', + id: 'tech-committee-charter', + }, + ], + }, + { + type: 'doc', + id: 'interested-parties', + }, + { + type: 'doc', + id: 'ADOPTERS', + label: 'Adopters', + }, + { + type: 'doc', + id: 'presentations', + }, + { + type: 'doc', + id: 'branding-guidelines', + }, + { + type: 'doc', + id: 'technical-guidelines', + }, + { + type: 'doc', + id: 'SECURITY', + }, + ], +}; + +module.exports = sidebarCommunity; diff --git a/governance-charter.md b/governance-charter.md index 9daf82d4..75204a46 100644 --- a/governance-charter.md +++ b/governance-charter.md @@ -1,77 +1,33 @@ -# OpenFeature Governance Charter +# Governance Charter ## Overview -This document describes the bootstrap governance process under which the project will operate -until the final governance process is identified. - -> :warning: This is a temporary (aka bootstrap) governance document that -> is effective until the project is fully established. -> See [this issue](https://github.com/open-feature/governance/issues/11) for the scope of the full governance document. +This document describes the governance process under which the project operates. +It describes the election process for the _Governance Committee_ (GC) and how the committee operates. ## Goals -The initial role of the governance committee is to **instantiate the formal -process for OpenFeature governance**. In addition to defining the initial -governance process, the bootstrap committee strongly believes that **it is -important to provide a means for iterating** the processes defined by the -governance committee. We do not believe that we will get it right the first -time, or possibly ever, and won’t even complete the governance development in a -single shot. The role of the governance committee is to be a live, responsive +The role of the _Governance Committee_ is to be a live, responsive body that can refactor and reform as necessary to adapt to a changing project and community. ## Governance Committee -The _Governance Committee_ is responsible for -representing the project, +The _Governance Committee_ is responsible for representing the project, making a final decision if a consensus cannot be reached (see _Decision Making_), handling the Code of Conduct escalations, defining and approving with the project members the final governance model, and organizing elections for the elected governance board body. ### Governance Committee Members -[Governance Committee Members](https://github.com/open-feature/community/blob/main/community-members.md#governance-board) - -> NOTE: -> In April 2022 _Project Maintainers_ assigned five seven individuals to be members of the _Bootstrap Governance Committee_. -> This is a **temporary** arrangement that should be replaced by an elected governing body before March 2024. - -## Technical Committee (TC) - -The project has a _Technical Committee (TC)_ -that consists of three maintainers who actively contribute to the project. -The role of the technical committee is to facilitate development of the -OpenFeature specification and other technical decisions in the project. -The responsibilities include reviewing the incoming enhancement proposal and pull requests, -driving the decision making process -and building consensus among the OpenFeature community. -At the moment, TC members do not get special permissions beyond what other maintainers have. - -### TC Members -[Technical Committee Members](./community-members.md#technical-committee) - -### TC Charter - -The technical committee is initially bootstrapped by 3 -contributors based on the consensus of contributors and maintainers of the project. -Their term is **one year**. -Then the technical committee members are re-elected based on the public nomination and decision making process. -The same happens when a TC member steps down from the role in the middle of the term, -an acting TC member is appointed by the community until the end of the term. - -At any time, less than 50% of the TC members can be affiliated with a single company. -If the affiliation changes during the term and violates the rule, -one of the TC members should step down. +[Governance Committee Members](./community-members.md#governance-board) ## Decision making Decisions are made by a consensus of _Project Members_ and [Interested Parties](./interested-parties.md). If this consensus cannot be reached, -the decision can be made by the plain majority vote of _Bootstrap Governance Committee Members_. - - +the decision can be made by the plain majority vote of _Governance Committee_ members. Key discussions and decisions should happen asynchronously in communication channels like GitHub Issues, discussions or pull requests. Technical decisions are expected to be documented in the @@ -85,40 +41,118 @@ hosted by its maintainers and contributors. These meetings are used as additional discussion and consensus building but not for making decisions without prior discussion in async channels. -### Project roles +#### Governance Committee Members + +_Governance Committee_ members are responsible for representing the project in communications with organizations, +including but not limited to contributor companies, adopters, vendors and foundations. +Apart from the representative role, +they can make a final decision when a consensus cannot be reached. +Each company/organization should have less than 50% of the seats. + +## Elections -The following project roles are defined at the moment: -_Community Participant_, -_Contributor_, -_Organization Member_, -_Triager_, -_Approver_, -_Maintainer_, -_Technical Committee Member_, -_Bootstrap Governance Committee Member_. -These roles are defined below. +### Members -See [Contributor Ladder](./CONTRIBUTOR_LADDER.md) for additional information. +People which are part of the GitHub Organization are considered as members and are eligible to vote. -In addition to the elected maintainer roles, -3 individuals get the maintainer status at the inception of the project: +### Eligibility for candidacy -- Michael Beemer, @beeme1mr, Dynatrace -- Alois Reitbauer, @AloisReitbauer, Dynatrace/CNCF/Keptn -- Oleg Nenashev, @oleg-nenashev, Dynatrace/CDF/Jenkins/Keptn +Anyone may nominate either themselves or someone else to be a candidate in the +election. To be ratified as a candidate, the nominee must accept the nomination +and three Members (including the nominator, if they are a member) +from three different employers, must endorse the nomination. -#### Bootstrap Governance Committee Members +Nominators are free to nominate as many people as they wish to. Members +may endorse multiple nominees, but we expect endorsements to be in good +faith. If this turns out to be a problem, this will be reconsidered. -> :warning: This is a **temporary role** while the bootstrap governance is active. -> In the future this role will be replaced by an elected _Governance Committee Member_ role. +### Eligibility for voting + +All organization members are eligible to vote for the _Governance Committee_ members. + +### Election process + +Elections will be held using time-limited approval voting on +[Helios](https://vote.heliosvoting.org/). The top vote getters will be elected +to the respective positions. + +### Maximal representation + +To encourage diversity there will be a maximum of one-third representation on +the _Governance Committee_ from any one company at any time. If the outcomes of +an election result in greater than 1/3 representation (or maximum of two, +whichever is greater), the lowest vote getters from any particular company will +be removed until representation on the committee is equal or less than one-third. + +If percentages shift because of job changes, acquisitions, or other events, +sufficient members of the committee must resign until max one-third +representation is achieved. If it is impossible to find sufficient members to +resign, the entire company’s representation will be removed and new special +elections held. In the event of a question of company membership (for example +evaluating independence of corporate subsidiaries) a majority of all +non-involved _Governance Committee_ members will decide. + +### Initial Election + +The bootstrap committee will operate the election and circulate a timeline for +nominations, and the vote. + +### Special Elections + +In the event of a resignation or other loss of a _Governance Committee_ member, a +special election for that position will be held as soon as possible. The same +group of people as described in "eligibility for voting" will vote in the +special election. A committee member elected in a special election will serve +out the remainder of the term for the person they are replacing, regardless of +the length of that remainder. + +### Limiting Corporate Campaigning Support + +To reduce the size of company advantages, candidates may not use their companies +internal or external brand to campaign. Their employers cannot solicit votes on +their behalf or sponsor candidates from partner organizations. Simply put, +elections highlight individuals outside of their corporate role and should be +treated as "brand free" activities. + +## Refactoring or reforming the governance committee + +At any time the _Governance Committee_ may vote, via supermajority (greater than +two-thirds of votes), to rewrite or remove any part of this charter. Beyond +small tweaks, this should be used sparingly, if ever, and in the presence of +clear failures of the process. We explicitly do not allocate a role for the +broader community in reformulating governance, we believe that in such a case +the community will "vote with their feet" by either leaving or forking the +project. + +## Inactivity + +It is important for _Governance Committee_ to be and stay active to set an example and show commitment to the project. Inactivity is harmful to the project as it may lead to unexpected delays, contributor attrition, and a lost of trust in the project. + +- Inactivity is measured by: + - Periods of no contributions for longer than 3 months + - Periods of no communication for longer than 3 months +- Consequences of being inactive include: + - Involuntary removal or demotion + - Being asked to move to Emeritus status + +## Involuntary Removal or Demotion + +Involuntary removal/demotion of a _Governance Committee_ happens when responsibilities and requirements aren't being met. This may include repeated patterns of inactivity, extended period of inactivity, a period of failing to meet the requirements of your role, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opens up opportunities for new people to step in. + +Involuntary removal or demotion is handled through a vote by a majority of the current _Governance Committee_. + +## Stepping Down/Emeritus Process + +If and when _Governance Committee_ members commitment levels change, they can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project). + +Contact the _Governance Committee_ about changing to Emeritus status, or stepping down. + +Members of the _Governance Committee_ will graduate to becoming *Emeritus* members +of the _Governance Committee_ once their term ends. + +## Contact + +- For inquiries, please reach out to: + - members of the [Governance Committee](https://github.com/open-feature/community/blob/main/community-members.md#governance-board) -Bootstrap Governance Committee members are responsible for representing the project in communications with organizations, -including but not limited to contributor companies, adopters, vendors and foundations. -Apart from the representative role, -they can make a final decision when a consensus cannot be reached. -In April 2022 this role will be assigned by project maintainers to **seven** individuals listed in [Interested Parties](./interested-parties.md). -Each company/organization should have less than 50% of the seats, -and hence an organization can have only up to three seats. -The project maintainers are also responsible to review their nominations with the community, -and to do the best effort to address any feedback/concerns. diff --git a/interested-parties.md b/interested-parties.md index 1ac6b661..464eba20 100644 --- a/interested-parties.md +++ b/interested-parties.md @@ -10,50 +10,64 @@ in a pull request. For individuals referencing the organization and other affiliations is optional. Organizations must specify a contact email and ensure it is kept up to date. -We invite interested parties to sign-up for news and to share expectations using [this Google Form](https://docs.google.com/forms/d/e/1FAIpQLSfRG8Ldun3HmcUsZCFMMORKyafjEUUKDYz5X-Zv8ZFCgbwlXA/viewform). -Everyone is also welcome to [participate and contribute](https://openfeature.dev/home/participate/) to the project. +We invite interested parties to sign-up for news and to share expectations using our [CNCF Mailing List](https://lists.cncf.io/g/cncf-openfeature-project). +Everyone is also welcome to [participate](https://openfeature.dev/community/contributor_ladder/) and [contribute](https://github.com/open-feature/.github/blob/main/CONTRIBUTING.md) to the project. ## Interested individuals | Person | Organization | Other Affiliations | GitHub Username | Gitlab Username | | ------------------- | --------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------- | +| Adam Gardner | Dynatrace. | CNCF, CDF, Keptn, Ortelius, CDEvents | [agardnerit](https://github.com/agardnerit) | | | Alex Jones | Canonical | TAG App Delivery, CDF | [alexsjones](https://github.com/AlexsJones) | N/A | | Alexandre Burgoni | Conduktor | | [AlexandreBrg](https://github.com/AlexandreBrg) | [Protocole](https://gitlab.com/Protocole) | | Alois Reitbauer | Dynatrace | CNCF TAG AppDelivery, Keptn | [Alois Reitbauer](https://github.com/AloisReitbauer) | N/A | +| Ankit Jain | VWO | | [Ankit Jain](https://github.com/ankneo) | N/A | +| Austin Drenski | | | [austindrenski](https://github.com/austindrenski) | [austindrenski](https://gitlab.com/austindrenski) | | Ben Rometsch | Flagsmith | | [dabeeeenster](https://github.com/dabeeeenster) | [dabeeeenster](https://gitlab.com/dabeeeenster) | +| Chris Joy | Flagbase | | [cjoy](https://github.com/cjoy) | [cjoy](https://gitlab.com/cjoy) | +| Craig Pastro | Pangea | | [craigpastro](https://github.com/craigpastro) | N/A | | Dan O'Brien | LaunchDarkly | | [intheclouddan](https://github.com/intheclouddan) | N/A | | Daniel Dyla | Dynatrace | OpenTelemetry | [dyladan](https://github.com/dyladan) | N/A | | Dave Johnston | Harness | | [davejohnston](https://github.com/davejohnston) | N/A | | David Božjak | Storytel | | [davidbozjak](https://github.com/davidbozjak) | N/A | -| David Hirsch | Dynatrace | TODO | [DavidPHirsch](https://github.com/DavidPHirsch) | N/A | +| David Hirsch | Dynatrace | TODO | [DavidPHirsch](https://github.com/DavidPHirsch) | N/A | | Dipto Chakrabarty | CISCO | Kubernetes | [diptochakrabarty](https://github.com/DiptoChakrabarty) | N/A | | Dominik Fleischmann | Canonical | Kubeflow | [DomFleischmann](https://github.com/DomFleischmann) | N/A | +| Fernando Bandeira | Alternative Payments | | [fernandobandeira](https://github.com/fernandobandeira) | N/A | +| Ganga Maddur | eBay | | [gangams20](https://github.com/gangams20) | N/A | | Gergely Sinka | ConfigCat | | [sigewuzhere](https://github.com/sigewuzhere) | N/A | -| Ihor Sychevskyi | N/A | | [Arhell](https://github.com/Arhell) | [Arhell](https://gitlab.com/Arhell) | +| Ihor Sychevskyi | N/A | | [Arhell](https://github.com/Arhell) | [Arhell](https://gitlab.com/Arhell) | | Ivar Østhus | Unleash | | [ivarconr](https://github.com/ivarconr) | | -| James Milligan | NET Reply | | [James-Milligan](https://github.com/James-Milligan) | N/A | -| Jason Wang | Statsig | Istio | [jasonwzm](https://github.com/jasonwzm) | N/A | +| James Carr | Starfish Prime | | [jamescarr](https://github.com/jamescarr) | N/A | +| James Kebinger | Prefab | | [jkebinger](https://github.com/jkebinger) | [jkebinger](https://gitlab.com/jkebinger) | +| James Milligan | NET Reply | | [James-Milligan](https://github.com/James-Milligan) | N/A | +| Jason Wang | Statsig | Istio | [jasonwzm](https://github.com/jasonwzm) | N/A | | Jeremy Dorn | GrowthBook | | [jdorn](https://github.com/jdorn) | N/A | | John Rowley | SEL | | [robbert229](https://github.com/robbert229) | N/A | | Jose Colella | Gusto | | [josecolella](https://github.com/josecolella) | N/A | -| Justin Abrahms | eBay | CDF, TODO | [justinabrahms](https://github.com/justinabrahms) | [justinabrahms](https://gitlab.com/justinabrahms) | +| Justin Abrahms | | CDF, TODO | [justinabrahms](https://github.com/justinabrahms) | [justinabrahms](https://gitlab.com/justinabrahms) | | Kevin Chu | GitLab | | [kbychu](https://github.com/kbychu) | [kbychu](https://gitlab.com/kbychu) | -| Krishika Singh | Harness | |[krishi0408](https://github.com/krishi0408) | N/A | +| Krishika Singh | Harness | | [krishi0408](https://github.com/krishi0408) | N/A | | Lajos Szoke | ConfigCat | | [laliconfigcat](https://github.com/laliconfigcat) | N/A | +| Lars Opitz | eBay | | [lopitz](https://github.com/lopitz) | N/A | +| Lev Lazinskiy | Dagger | | [levlaz](https://github.com/levlaz) | [levlaz](https://gitlab.com/levlaz) | | Liam Jameson | Syntoniq | | [L14MJ4M3S0N](https://github.com/L14MJ4M3S0N) | N/A | +| Liran Mendelovich | Proofpoint | | [liran2000](https://github.com/liran2000) | N/A | | Luis Silva | RemoteFlags | | [luiscrs14](https://github.com/luiscrs14) | N/A | | Mark Phelps | Flipt | | [markphelps](https://github.com/markphelps) | N/A | | Max Körbächer | Liquid Reply | Kubernetes | [mkorbi](https://github.com/mkorbi) | N/A | +| Max VelDink | Justworks | | [maxveldink](https://github.com/maxveldink) | N/A | | Michael Beemer | Dynatrace | | [beeme1mr](https://github.com/beeme1mr) | [beeme1mr](https://gitlab.com/beeme1mr) | | Michael Friedrich | GitLab | | [dnsmichi](https://github.com/dnsmichi) | [dnsmichi](https://gitlab.com/dnsmichi) | | Michael Winkler | Dynatrace | | [miigwi](https://github.com/miigwi) | N/A | | Mitch Connors | Google | Istio, cobra | [therealmitchconnors](https://github.com/therealmitchconnors) | N/A | -| Moshe Beladev | Torq | Gebug, gTrace | [moshebe](https://github.com/moshebe) | N/A | +| Moshe Beladev | Torq | Gebug, gTrace | [moshebe](https://github.com/moshebe) | N/A | | Oleg Nenashev | Dynatrace | CDF, Jenkins, Keptn, FOSSi, API Neuchatel | [oleg-nenashev](https://github.com/oleg-nenashev) | [oleg-nenashev](https://gitlab.com/oleg-nenashev) | | Patricio Echague | Split.io | | [patricioe](https://github.com/patricioe) | N/A | | Pete Hodgson | Independent | | [moredip](https://github.com/moredip) | N/A | | Renjith Pillai | SAP | | [vrenjith](https://github.com/vrenjith) | N/A | -| Roberth Strand | Crayon Group | CNCF (TAG App Delivery, OpenGitOps, Cooperative Delivery WG) | [roberthstrand](https://github.com/roberthstrand) | N/A | +| Roberth Strand | Crayon Group | CNCF (TAG App Delivery, OpenGitOps, Cooperative Delivery WG) | [roberthstrand](https://github.com/roberthstrand) | N/A +| Sajib Adhikary | N/A | | [sajibadhi](https://github.com/sajibadhi) | [sajibadhi](https://gitlab.com/sajibadhi) | Skye Gill | NET Reply | | [skyerus](https://github.com/skyerus) | N/A | | Stephen Augustus | Cisco | CNCF, OpenSSF, Inclusive Naming Initiative, TODO Group, Kubernetes, Dex | [justaugustus](https://github.com/justaugustus) | [justaugustus](https://gitlab.com/justaugustus) | | Steve Arch | CloudBees | | [agentgonzo](https://github.com/agentgonzo) | N/A | @@ -62,9 +76,9 @@ Everyone is also welcome to [participate and contribute](https://openfeature.dev | Tim Glaser | PostHog | | [timgl](https://github.com/timgl) | N/A | | Todd Baert | Dynatrace | ISC2 | [toddbaert](https://github.com/toddbaert) | N/A | | Tom Carrio | Skillshare | | [tcarrio](https://github.com/tcarrio) | [tcarrio](https://gitlab.com/tcarrio) | -| Vic Vuci | DevCycle | Taplytics | [vicv](https://github.com/vicv) | [vicv](https://gitlab.com/vicv) | -| Weyert de Boer | Tapico | Opentelemetry, OpenSLO | [weyert](https://github.com/weyert) -| Yousef Soliman | N/A | | [yousef-soliman](https://github.com/yousef-soliman) | N/A +| Vic Vuci | DevCycle | Taplytics | [vicv](https://github.com/vicv) | [vicv](https://gitlab.com/vicv) | +| Weyert de Boer | FNZ | Opentelemetry, OpenSLO | [weyert](https://github.com/weyert) | +| Yousef Soliman | N/A | | [yousef-soliman](https://github.com/yousef-soliman) | N/A | | Zoltan David | ConfigCat | | [zoltan-david](https://github.com/zoltan-david) | N/A | _Sorted alphabetically by first name_ @@ -75,12 +89,15 @@ List of companies, organizations, foundations and other groups that declared int | Organization | Website link | Contact Email/Information | Testimonial/case study link | | --------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------- | +| Alternative Payments | [alternativepayments.io](https://www.alternativepayments.io/) | `fernando at alternativepayments.io` | N/A | +| AWS AppConfig | [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) | `aws-appconfig-contact at amazon.com` | N/A | | Cisco | [opensource.cisco.com](https://opensource.cisco.com/) | `augustus at cisco.com` | N/A | | CloudBees | [cloudbees.com](https://www.cloudbees.com/products/feature-management) | [Contact CloudBees support](https://www.cloudbees.com/products/feature-management/contact-us) | N/A | | ConfigCat | [configcat.com](https://configcat.com/) | `opensource at configcat.com` | N/A | -| DevCycle | [devcycle.com](https://devcycle.com/) | `support at devcycle.com` | N/A | +| DevCycle | [devcycle.com](https://devcycle.com/) | `support at devcycle.com` | N/A | | Dynatrace | [dynatrace.com](https://www.dynatrace.com/) | `opensource at dynatrace.com` | N/A | | eBay | [ebay.com](https://ebay.com) | `opensource at ebay.com` | N/A | +| Flagbase | [flagbase.com](https://flagbase.com/) | `info at flagbase.com` | N/A | | Flagship.io | [flagship.io](https://www.flagship.io/) | `support at flagship.io` | N/A | | Flipt | [flipt.io](https://flipt.io/) | `support at flipt.io` | N/A | | Flagsmith | [flagsmith.com](https://flagsmith.com/) | `support at flagsmith.com` | N/A | @@ -88,12 +105,16 @@ List of companies, organizations, foundations and other groups that declared int | Go Feature Flag | [GO Feature Flag](https://gofeatureflag.org/) | `contact at gofeatureflag.org` | N/A | | GrowthBook | [growthbook.io](https://www.growthbook.io) | `info at growthbook.io` | N/A | | Harness | [harness](https://harness.io/) | `support at harness.io` | N/A | +| Kameleoon | [kameleoon.com](https://kameleoon.com/) | `support at kameleoon.com` | N/A | | LaunchDarkly | [launchdarkly.com](https://launchdarkly.com) | `support at launchdarkly.com` | N/A | | PostHog | [PostHog](https://www.posthog.com/) | `hey at posthog.com` | N/A | +| Prefab | [Prefab](https://www.prefab.cloud/) | `support at prefab.cloud` | N/A | | RemoteFlags | [RemoteFlags](https://remoteflags.com/) | `info at remoteflags.com` | N/A | | Split.io | [split.io](https://split.io/) | `support at split.io` | N/A | | Statsig | [Statsig](https://www.statsig.com) | `suppport at statsig.com` | N/A | | Storytel | [Storytel](https://www.storytel.com) | `support.se at storytel.com` | N/A | | Unleash | [Unleash](https://www.getunleash.io/) | `contact at getunleash.io` | N/A | +| VWO | [VWO](https://vwo.com/) | `support at vwo.com` | N/A | + _Sorted alphabetically by organization_ diff --git a/mission-vision.md b/mission-vision.md index d2da6ec0..b0e5a629 100644 --- a/mission-vision.md +++ b/mission-vision.md @@ -1,4 +1,4 @@ -# OpenFeature Mission and Vision +# Mission and Vision ## Mission @@ -8,7 +8,7 @@ To improve the software development lifecycle, no matter the size of the project A world where feature flagging is a core principle of the software development lifecycle, enabling teams to test and release high quality software with a high degree of safety and confidence. -OpenFeature can achieve this vision by: +**OpenFeature can achieve this vision by:** ### Vendor neutrality @@ -28,6 +28,6 @@ OpenFeature is a collective effort that benefits from years of experience across Feature flagging is a simple, yet powerful mechanism that improves the entire software development lifecycle by decoupling feature release from a deployment. It isn't, however, ubiquitously used throughout the industry. OpenFeature is an opportunity to promote good software practices in a vendor neutral way through developing feature flag awareness. -[glossary-app-auth]: https://github.com/open-feature/spec/blob/main/specification/glossary.md#application-author -[glossary-app-int]: https://github.com/open-feature/spec/blob/main/specification/glossary.md#application-integrator -[glossary-provider]: https://github.com/open-feature/spec/blob/main/specification/glossary.md#provider +[glossary-app-auth]: https://openfeature.dev/docs/specification/glossary#application-author +[glossary-app-int]: https://openfeature.dev/docs/specification/glossary#application-integrator +[glossary-provider]: https://openfeature.dev/docs/specification/glossary#provider diff --git a/presentations.md b/presentations.md new file mode 100644 index 00000000..214bfe57 --- /dev/null +++ b/presentations.md @@ -0,0 +1,26 @@ +# Presentations + +This page showcases presentation given by the OpenFeature community, providing links to past presentations, and offering resources for community members who wish to contribute to future presentations. + +## Previous presentations + +This section provides an overview of all the presentations given by the OpenFeature community, including links to recordings and slides where available. +All items are listed in reverse chronological order from when they were first presented. + +| Title | Event | Recording | Slides | +| ------------------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | +| Feature Flagging in the SDLC | N/A | N/A | [Link](https://docs.google.com/presentation/d/1aIKUI2L3NlAnSguOrSr3zXOC4hriPpgA383a-sTyAQk/) | +| Architecture and Patterns of OpenFeature | N/A | N/A | [Link](https://docs.google.com/presentation/d/1gganwGmlpp8Lb_bYvw-uysrKzLqMYS4stx_vtSEy1HY) | +| OpenFeature, with Thomas Poignant and Todd Baert | Kubernetes Podcast | [Link](https://kubernetespodcast.com/episode/224-openfeature/) | N/A | +| Feature Observability | KubeCon EU 24 | [Link](https://www.youtube.com/watch?v=euYhIn4leW0) | [Link](https://docs.google.com/presentation/d/1ZvW-6dZdfJCH9qEMKAWPCp6aTzt2Us65) | +| Feature Management Improv | KubeCon EU 24 | [Link](https://www.youtube.com/watch?v=wkmryOXmVaw) | [Link](https://docs.google.com/presentation/d/1aXp41SY7ChsYc728NXlo-vaX2Ekme1J5r9cmgwC5JYc) | +| KubeCon Booth | KubeCon EU 24 | N/A | [Link](https://docs.google.com/presentation/d/1yu575WbbZRMXUwRMzgIQFgEEly2P8fnJ) | +| Breaking up is(n't) hard to do! | DevOpsDays NYC 23 | [Link](https://www.youtube.com/watch?v=_6B8-qEEyvo) | [Link](https://docs.google.com/presentation/d/1bkHK6_CapZ-iPrhoLDZuOfolyxIx-_Xduq_hxBsvYVs) | +| KubeCon Booth | KubeCon US 23 | N/A | [Link](https://docs.google.com/presentation/d/1ApvcVPf3NgV1Otv4B2VuoBYOwTSvyLD4pQz0M2xizds) | +| An introduction to Feature Flagging & OpenFeature | CNCF On-demand Webinar | [Link](https://www.cncf.io/online-programs/cncf-on-demand-webinar-an-introduction-to-feature-flagging-openfeature/) | N/A | + +> Recently presented on OpenFeature? [Let us know](https://github.com/open-feature/community/issues/new) so we can add you to the list! + +## Additional resources + +Please refer to the [OpenFeature branding guidelines](./branding-guidelines.md) for information on naming conventions, logos, colors and more. diff --git a/project-infrastructure/README.md b/project-infrastructure/README.md deleted file mode 100644 index d2a97d2d..00000000 --- a/project-infrastructure/README.md +++ /dev/null @@ -1,41 +0,0 @@ -# OpenFeature Project Infrastructure - -This page lists the resources used by the OpenFeature project. - -## Contributing - -We welcome all contributions to managing project infrastructure and content there. -If you are interested to participate, contact us in the `#openfeature` channel on the CNCF Slack. - -## GitHub - -The project uses the [open-feature GitHub organization](https://github.com/open-feature). -This organization includes all the repositories, including specification, implementations, community governance, -and the website currently hosted on GitHub pages. - -Managers: Michael Beemer, Alois Reitbauer, Oleg Nenashev. - -## CNCF Community chapter - -Coming soon - -## Google Drive - -Most of the documents are stored in this [Google Drive Directory](https://drive.google.com/drive/folders/1NeJIFyfCV7ONNnLMKroy2gg09CCSXW9W?usp=sharing). -It will be moved to another vendor neutral location later. -We keep the documents public when possible. - -Managers: Oleg Nenashev, Michael Beemer, Alois Reitbauer. - -## Public calendar - -The public Google calendar is available [here](https://calendar.google.com/calendar/u/0?cid=MHVhN2kxaGl2NWRoMThiMjd0b2FoNjM2NDRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ). -Events will be added by the calendar management upon request. - -Managers: Oleg Nenashev, Michael Beemer, Alois Reitbauer. - -## Slack - -- `#openfeature` channel on the CNCF Workspace, managed via CNCF helpdesk -- Dedicated OpenFeature workspace on Slack: coming soon - diff --git a/tech-committee-charter.md b/tech-committee-charter.md index 919cf38b..b8bb042b 100644 --- a/tech-committee-charter.md +++ b/tech-committee-charter.md @@ -1,11 +1,20 @@ +--- +title: Technical Committee Charter +sidebar_position: 21 +--- # Technical Committee Charter + +### TC Members + +[Technical Committee Members](./community-members.md#technical-committee) + ## Guiding Principle The OpenFeature project will operate transparently, collaboratively, ethically, and in alignment with the interests of OpenFeature technology end-users. Project proposals, timelines, and status must not merely be open, but also easily visible to and discoverable by outsiders. ## Evolution of OpenFeature Governance -Most large, complex open source communities have both a business and a technical governance model. OpenFeature has a project-level Governance Committee, a project-level Technical Committee, and is a Sandbox project in the Cloud Native Computing Foundation. +Most large, complex open source communities have both a business and a technical governance model. OpenFeature has a project-level Governance Committee, a project-level Technical Committee, and is an Incubating project in the Cloud Native Computing Foundation. This OpenFeature Technical Committee Charter reflects the scope and expectations of the Technical Committee ("TC") with the maintainers, the consumers, and the ecosystem of the project. The charter will not be perfect, and so has a simple amendment process – a TC member proposes changes to be discussed and voted on by the full TC. @@ -19,21 +28,44 @@ Changes to TC membership should be posted in the agenda document, and may be sug ### No Over-Representation - -### Participation +No more than one-third (33%) of the TC members may be affiliated with the same employer (same employer defined as "representing the same legal entity/project"). If removal or resignation of a TC member, or a change of employment by a TC member, creates a situation where more than one-third of the TC membership shares an employer, then the situation must be immediately remedied by the election of one or more TC members. ## Responsibilities of the Technical Committee +The TC ensures that the project maintains a high level of technical excellence while continuing to meet the needs of its adopters, and facilitates ongoing community contribution. + +The TC is responsible for: +- Setting technical goals and priorities. +- Participation in specification development. +- Resolving disputes and disagreements about technical matters within the community. +- Establishing and enforcing technical standards and practices. +- Providing guidance to new contributors. +- Ensuring proper stewardship and oversight of project components and repositories. +- Participation in meetings facilitated by the TC Chair. -## OpenFeature Project Operations +Some specific examples of activities TC members might be involved in include, but are not limited to: +- Ensuring new maintainer(s) for a particular SDK are identified when a previous maintainer leaves. +- Resolving a dispute over whether or not a particular change is considered "breaking". +- Ensuring repositories and releases conform to the [established requirements](https://github.com/open-feature/.github/blob/main/CONTRIBUTING.md#repository-requirements). +- Reviewing [specification](https://github.com/open-feature/spec) PRs and [OFEPs](https://github.com/open-feature/ofep). +- Creating and reviewing [projects](https://github.com/orgs/open-feature/projects). +- Contributing to the development of a vulnerability reporting policy. +- Reviewing donated repositories, and identifying maintainers for the donated code. +- Archiving a repository that cannot be maintained due to lack of maintainers. +### Participation -### Code Donations +It's the responsibility of the [TC Chair](#election-of-tc-chair) to facilitate meetings or other asynchronous mechanisms of communication within the TC. +The frequency and mode of the meetings is to be decided by the chair, taking into consideration the availability of TC members. +TC members are expected to regularly attend meetings and participate in communication modes facilitated by the TC Chair. +### Conflicts of Interest +TC members will avoid taking actions or making decisions that constitute a conflict of interest. +In such cases, TC members will inform the the wider TC of the perceived conflict and the issue will be resolved by another member. ## Elections @@ -41,17 +73,8 @@ Changes to TC membership should be posted in the agenda document, and may be sug ### Election of TC Members - +New TC members can be nominated by an existing TC Member. A candidate can be elected to the TC by the super-majority vote (greater than two thirds) of the existing TC members. The GC will have a veto for the new members. ### Election of TC Chair - - -## Voting on project issues - - - - -## Project Roles - - +The TC Chair will rotate amongst TC members. The responsibilities of TC Chair include: building an agenda for TC meetings, encouraging participation of other members and facilitating the decisions among TCs. The TC Chairperson should hold their role for 3 months; there are no limits on the number of terms a TC Chairperson may serve. diff --git a/technical-guidelines.md b/technical-guidelines.md new file mode 100644 index 00000000..eaedb997 --- /dev/null +++ b/technical-guidelines.md @@ -0,0 +1,143 @@ +# Technical Guidelines + +## Developer Certificate Of Origin + +The [Developer Certificate of Origin (DCO)](https://developercertificate.org/) is a lightweight way for contributors +to certify that they wrote or otherwise have the right to submit the code they are contributing to the project. + +Contributors to the OpenFeature project sign-off that they adhere to these requirements by adding a `Signed-off-by` line to commit messages. + +```console +This is my commit message + +Signed-off-by: John Doe +``` + +Git even has a `-s` command line option to append this automatically to your commit message: + +```console +git commit -s -m 'This is my commit message' +``` + +If you have already made a commit and forgot to include the sign-off, you can amend your last commit +to add the sign-off with the following command, which can then be force pushed. + +```console +git commit --amend -s +``` +## Repository requirements + +We require repositories in the project adhere to some security and maintenance guidelines. +They are primarily inspired by recommendations from the [Cloud Native Security Controls Catalog](https://www.cncf.io/blog/2022/06/07/introduction-to-the-cloud-native-security-controls-catalog/). +Adherence to these guidelines is required for 1.0 artifact releases, to the satisfaction of the [Technical Steering Committee](./tech-committee-charter.md). + +| Requirement | Recommended solution(s) | Notes | +| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | +| automated publishing | github actions (with permissions applying principle of least privilege), language-specific tools (Maven, nuget, NPM, etc) | required | +| container, base image scanning | [snyk][snyk], [trivy][trivy] | required | +| code ownership | branch protection rules\* and CODEOWNERS files | required | +| dependency analysis | [snyk][snyk] | required | +| dependency auto-updates | [Renovate][renovate]\*\*, [Dependabot][dependabot] | required | +| semantic versioning, changelogs | [Semantic Versioning][semantic-versioning], [Conventional Commits][conventional-commits], [Release Please][release-please]\*\*\* | required | +| unit, integration testing | github actions (with permissions applying principle of least privilege), language-specific tools (JUnit, Jest, etc), [Cucumber][cucumber] | required, with coverage metrics up to maintainer discretion | +| signing (binaries, packages, container images) | language-specific tools, [cosign][cosign] | recommended, where supported | +| fuzzing | [ClusterFuzzLite][clusterfuzzlite], [OSS-Fuzz][oss-fuzz] | recommended | +| helpful readme file | See [example README.md](https://github.com/open-feature/.github/blob/main/templates/READMEs/README.md) | recommended | +| provenance | [SLSA](https://slsa.dev/spec/v1.0/provenance#provenance) | recommended | +| SBOM generation | [CycloneDX][cyclonedx], [SPDX][spdx], [syft][syft] | recommended | +| static analysis | [SonarCloud][sonarcloud], language-specific tools (SpotBugs, eslint) | recommended | + +\* Branch protection rules should protect the primary branch (usually `main`) by requiring code review from the appropriate parties (other than the author), usually expressed in a CODEOWNERS file. + +\*\* We recommend Renovate over Dependabot because of its group and auto-merge features. +Additionally, we have an org-wide base config for Renovate. + +\*\*\* Release Please isn't strictly necessary, but combined with [Conventional Commits][conventional-commits], it provides a simple yet robust means of generating useful, accurate changelogs and releasing semantically versioned artifacts. + +### "Contrib" repositories + +Along with SDK repositories, we also maintain "contrib" repositories for most of our supported languages. +These repositories are "monorepos" that house community contributions which are extensions to, or integrations with, the base SDKs. +Examples include providers, hooks and framework-specific SDKs. +In addition to the normal [repository requirements](#repository-requirements) (many of which are already implemented for all packages in each monorepo), components must each have _at least_ one user specified the `component_owners.yml` (see https://github.com/dyladan/component-owners for more). It's the responsibility of the `component_owner(s)` to: + +- review and resolve issues pertaining to their component +- review and resolve pull requests pertaining to their component, including automated pull requests from dependabot, etc +- review releases PRs for new versions of their component +- alert the [Governance Board or Technical Committee](./community-members.md#technical-committee) if they're no longer interested or able to fulfill the preceding requirements + +Consistent and prolonged failure to satisfy the above requirements may result in archival and deprecation of the component in question. + +## Semantic Versioning and 1.0 Releases + +We require release artifacts to adhere to [semantic versioning](https://semver.org/) except in specific cases approved by the [Technical Steering Committee](./community-members.md#technical-committee). +1.0 releases must satisfy the [repository requirements](#repository-requirements) above. +If the artifact is an SDK implementing the OpenFeature specification, it must also conform to a version of the OpenFeature specification not less than 2 minor versions behind the latest (ex: if the latest OpenFeature specification is `0.8.1`, then an implementation conforming to `0.6.0` is a candidate for `1.0` release, while an implementation conforming only to `0.5.0` is not). +This policy may be subject to change with the release of the OpenFeature specification version `1.0.0`. + +> [!IMPORTANT] +> While the OpenFeature specification version is < `1.0`, it's possible breaking changes will be introduced. +> This may necessitate that SDKs which have released `1.0` versions, release `2.0` versions in order to adhere to breaking specification changes. + +> [!IMPORTANT] +> Note that features in the specification marked as `experimental` may change at any time, and implementations may choose to make breaking changes to such features disregarding semantic versioning conventions. +> See [specification document statuses](https://openfeature.dev/specification/#document-statuses). + +### Breaking Changes to Major Versions + +Efforts should be made to avoid breaking changes in `1.0+` artifacts. +If such changes are necessary, please consider the following: + +* How important is the breaking change? Is there a non-breaking alternative? +* Have the changes in question been marked as deprecated for some time? + * If possible, deprecate the functionality and give users some time to prepare for the changes in advance. +* How difficult would it be to backport emergency fixes to the previous version (enterprises on the old platform will almost certainly not be able to upgrade immediately, so backports for security fixes or severe bugs must be supported). + * It's highly recommended to create a `v(-1)` branch before introducing breaking changes, to support the release of such fixes. + * For example, if you are releasing a `2.0.0`, maintain a `v1` branch. + * [Release Please][release-please] can make maintenance and release of artifacts from such a branch easy; simply have the release-please action run on the branch, and target that branch for its PRs. + +Please consult with a member of the [TC](./community-members.md#technical-committee) before making breaking changes to a `1.0+` component. + +## Platform Support + +OpenFeature maintains SDKs and integrations targeting various platforms, runtimes, and frameworks. +For the purposes of this document, a "platform" constitutes an assumed underlying runtime dependency. +This includes, but is not limited to: languages, operating systems, dependency managers, virtual machines and software libraries. +This section describes our approach to supporting, and deprecating support for these. + +### Platform Support Recommendations + +* Efforts should be made to support the usage of OpenFeature libraries on all officially supported (non-EOL) platforms for the library in question (i.e.: a library for Node.js should support all officially supported versions of Node.js). +* Support should be documented explicitly in the relevant README, and in any implementation-specific tooling (ie: `engine` value in `package.json` or `maven.compiler.target` in `pom.xml`). + +### Removing Support for Platforms + +Removing support for a platform should not be done arbitrarily, but when maintenance becomes burdensome, consider the following when dropping support: + +* Is the platform officially supported? + * How recently was support dropped? +* Is the implicated OpenFeature component pre-release or `1.0+`? +* How popular is the implicated OpenFeature library at the moment? + * More usage means that the likelihood of usage by the platform to be deprecated is higher. +* Should this be considered a breaking change? + * **This is highly dependent on the platform in question, as well as how change averse its user base is** (ie: Go is a very fast moving platform relative to Java). + * How difficult will the required platform change be for users to consume? Does the new platform version contain many breaking changes? + * See [breaking changes to major versions](#breaking-changes-to-major-versions) + +Please consult with a member of the [TC](./community-members.md#technical-committee) before dropping support for a platform, runtime or framework version. + +[sonarcloud]: https://www.sonarsource.com/products/sonarcloud/ +[snyk]: https://snyk.io/ +[trivy]: https://github.com/aquasecurity/trivy +[cosign]: https://github.com/sigstore/cosign-installer +[cyclonedx]: https://cyclonedx.org/tool-center/ +[clusterfuzzlite]: https://google.github.io/clusterfuzzlite/ +[oss-fuzz]: https://github.com/google/oss-fuzz +[cucumber]: https://cucumber.io/tools/cucumber-open/ +[renovate]: https://github.com/apps/renovate +[syft]: https://github.com/anchore/syft +[spdx]: https://spdx.dev/resources/tools/ +[dependabot]: https://github.com/dependabot +[conventional-commits]: https://www.conventionalcommits.org/ +[semantic-versioning]: https://semver.org/ +[release-please]: https://github.com/googleapis/release-please