├── .github ├── CODE_OF_CONDUCT.md ├── ISSUE_TEMPLATE │ ├── paketo-buildpacks-sc-candidate-nomination.md │ ├── request-to-be-elector-for-paketo-buildpacks-sc-election.md │ ├── request-to-be-elector-for-toc-election.md │ ├── rfc-issue-template.md │ └── toc-candidate-nomination.md └── workflows │ ├── org-inactive-user-management.yml │ ├── org-management-check-prs.yml │ ├── org-management-ci.yml │ ├── org-management-peribolos-dump.yml │ ├── org-management.yml │ ├── project-sync.yml │ └── remove-individual-access.yml ├── .gitignore ├── CODEOWNERS ├── CONTRIBUTING.md ├── LICENSE ├── NOTICE ├── ORGS.md ├── README.md ├── ci └── docker │ └── ghproxy │ ├── Dockerfile │ └── entrypoint.sh ├── elections ├── 2021 │ └── TOC │ │ ├── README.md │ │ ├── ballots.csv │ │ ├── electiondescription.html │ │ ├── results.md │ │ └── voters.md ├── 2022 │ └── TOC │ │ ├── README.md │ │ ├── ballots.csv │ │ ├── candidate-AP-Hunt.md │ │ ├── candidate-beyhan.md │ │ ├── candidate-pburkholder.md │ │ ├── candidate-rkoster.md │ │ ├── election.yaml │ │ ├── election_desc.md │ │ ├── results.md │ │ └── voters.yaml ├── 2023 │ ├── Paketo-SC │ │ ├── README.md │ │ ├── ballots.csv │ │ ├── candidate-ForestEckhardt.md │ │ ├── candidate-dmikusa.md │ │ ├── candidate-loewenstein.md │ │ ├── election.yaml │ │ ├── election_desc.md │ │ ├── results.md │ │ └── voters.yaml │ └── TOC │ │ ├── README.md │ │ ├── ballots.csv │ │ ├── candidate-ChrisMcGowan.md │ │ ├── candidate-ameowlia.md │ │ ├── candidate-anEXPer.md │ │ ├── candidate-stephanme.md │ │ ├── election.yaml │ │ ├── election_desc.md │ │ ├── results.md │ │ └── voters.yaml ├── 2024 │ ├── Paketo-SC │ │ ├── README.md │ │ ├── ballots.csv │ │ ├── candidate-jericop.md │ │ ├── candidate-loewenstein-sap.md │ │ ├── election.yaml │ │ ├── election_desc.md │ │ ├── results.md │ │ └── voters.yaml │ └── TOC │ │ ├── README.md │ │ ├── candidate-beyhan.md │ │ ├── candidate-rkoster.md │ │ ├── election.yaml │ │ ├── election_desc.md │ │ ├── results.md │ │ └── voters.yaml └── 2025 │ ├── Paketo-SC │ ├── README.md │ ├── election.yaml │ └── election_desc.md │ └── TOC │ ├── README.md │ ├── election.yaml │ └── election_desc.md ├── governing-board └── charter.md ├── orgs ├── .flake8 ├── branchprotection.yml ├── contributors.yml ├── generate_working_group_projects_sync_config.sh ├── org_management.py ├── org_user_management.py ├── orgs.yml ├── orphaned_repos.sh ├── pyproject.toml ├── readme.md ├── requirements-dev.txt ├── requirements.txt └── test_org_management.py └── toc ├── ADMIN.md ├── CHANGEPLAN.md ├── PRINCIPLES.md ├── ROLES.md ├── TOC.md ├── elections ├── 2021 │ ├── README.md │ ├── results.md │ └── voters.md └── 2022 │ └── Readme.md ├── rfc ├── README.md ├── archived │ └── rfc-0005-github-teams-and-access.md ├── assign-rfc-number.sh ├── rfc-0001-jammy-os.md ├── rfc-0001-jammy-os │ └── jammy-jellyfish-cf-supply-chain.png ├── rfc-0002-github-members.md ├── rfc-0003-pr-only-workflow.md ├── rfc-0004-wg-visibility.md ├── rfc-0006-approver-requirements.md ├── rfc-0007-repository-ownership.md ├── rfc-0008-role-change-process.md ├── rfc-0009-efficient-modern-vm-sizes.md ├── rfc-0010-stemcell-cleanup.md ├── rfc-0011-move-buildpacks-dependencies-to-cff.md ├── rfc-0012-formal-aspiring-approvers-as-reviewers.md ├── rfc-0013-remove-nonstandard-github-teams.md ├── rfc-0014-github-teams-and-access.md ├── rfc-0015-branch-protection.md ├── rfc-0016-python-and-ruby-removal-from-cf-stack.md ├── rfc-0017-add-cnbs.md ├── rfc-0018-aggregate-metric-egress-with-opentelemetry-collector.md ├── rfc-0019-pcap-bosh.md ├── rfc-0019-pcap-bosh │ ├── tcpdump-bosh-pcap-lite.drawio.svg │ └── tcpdump-bosh-pcap-release.drawio.svg ├── rfc-0020-readiness-healthchecks.md ├── rfc-0021-toc-stand-in-for-wg-lead.md ├── rfc-0022-deprecate-metrics-agent.md ├── rfc-0023-add-cf-supports-for-fips-stemcell.md ├── rfc-0024-promoting-or-revoking-wg-leads.md ├── rfc-0025-define-criteria-and-removal-process-for-inactive-members.md ├── rfc-0026-noble-os.md ├── rfc-0027-generic-per-route-features.md ├── rfc-0028-cnb-lifecycle.md ├── rfc-0029-ssh-over-ws.md ├── rfc-0029-ssh-over-ws │ └── cf-ssh-over-websocket.drawio.png ├── rfc-0030-add-support-for-file-based-service-binding.md ├── rfc-0031-system-cnb.md ├── rfc-0032-cfapiv2-eol.md ├── rfc-0033-user-creation-by-org-managers.md ├── rfc-0034-v2-app-manifests.md ├── rfc-0035-add-bosh-release-property-validation.md ├── rfc-0036-multiple-github-orgs.md ├── rfc-0037-deprecate-passwords.md ├── rfc-0038-ipv6-dual-stack-for-cf.md ├── rfc-0039-noble-based-cflinuxfs5.md └── rfc-template.md └── working-groups ├── WORKING-GROUPS.md ├── app-runtime-deployments.md ├── app-runtime-interfaces.md ├── app-runtime-platform.md ├── app-runtime-platform └── working-agreements │ ├── 2021-10-28-how-to-make-working-agreements.md │ └── 2021-10-29-reviewer-workflows.md ├── cf-on-k8s.md ├── concourse.md ├── contributions-for-user.sh ├── docs.md ├── foundational-infrastructure.md ├── paketo.md ├── parsable-working-groups.sh ├── service-management.md └── vulnerability-management.md /.github/ISSUE_TEMPLATE/paketo-buildpacks-sc-candidate-nomination.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Paketo Buildpacks SC Candidate Nomination 3 | about: Paketo Buildpacks Steering Committee Candidate Nomination for Election Cycle 4 | title: Paketo Buildpacks Steering Committee Candidate Nomination for [Person Name] 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | Candidate Name: [name of person being nominated] 11 | 12 | Candidate GitHub Username: [GitHub username of person being nominated] 13 | 14 | Affiliation: [employer of candidate] 15 | 16 | Nomination Statement: [Describe why this person (or you!) would make a good member of the TSC] 17 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/request-to-be-elector-for-paketo-buildpacks-sc-election.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Request to be elector for Paketo Buildpacks SC election 3 | about: Requests for community members to be added as electors for a Paketo Buildpacks 4 | Steering Committee election cycle. 5 | title: Request to be elector for Paketo Buildpacks Steering Committee election 6 | labels: election 7 | assignees: '' 8 | 9 | --- 10 | 11 | Github Username: [put the username to be added] 12 | 13 | Affiliation: [employer of candidate] 14 | 15 | Community participation: [describe your community participation over the last year] 16 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/request-to-be-elector-for-toc-election.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Request to be elector for TOC election 3 | about: Requests for community members to be added as electors for a TOC election cycle. 4 | title: Request to be an elector for TOC election 5 | labels: election 6 | assignees: '' 7 | 8 | --- 9 | 10 | Github Username: [put the username to be added] 11 | 12 | Affiliation: [employer of candidate] 13 | 14 | Community participation: [describe your community participation over the last year] 15 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/rfc-issue-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: RFC Tracking 3 | about: This type of issues are used to track the status of RFCs 4 | title: "[RFC0XXX] " 5 | labels: rfc 6 | assignees: "" 7 | --- 8 | 9 | This is a tracking issue for [RFC](). 10 | 11 | **Delivered with**: 12 | - CF-Deployment version: 13 | - CLI version: 14 | - CF Docs: 15 | 16 | ### Tasks 17 | - [ ] Link PRs & issues... 18 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/toc-candidate-nomination.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: TOC Candidate Nomination 3 | about: TOC Candidate Nomination for Election Cycle 4 | title: TOC Candidate Nomination for [Person Name] 5 | labels: election 6 | assignees: '' 7 | 8 | --- 9 | 10 | Candidate Name: [name of person being nominated] 11 | 12 | Candidate GitHub Username: [GitHub username of person being nominated] 13 | 14 | Affiliation: [employer of candidate] 15 | 16 | Nomination Statement: [Describe why this person (or you!) would make a good member of the TOC] 17 | -------------------------------------------------------------------------------- /.github/workflows/org-inactive-user-management.yml: -------------------------------------------------------------------------------- 1 | name: 'Delete Inactive Users in Github Organization' 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 */32,1-7 * 1' 6 | workflow_dispatch: 7 | push: 8 | branches: 9 | - "add-inactive-user-removal-automation" 10 | 11 | jobs: 12 | org-config-generation-check: 13 | runs-on: ubuntu-latest 14 | steps: 15 | - uses: actions/setup-python@v5 16 | with: 17 | python-version: 3.13 18 | - uses: actions/checkout@v4 19 | with: 20 | path: community 21 | - name: Clean inactive github org users 22 | id: uds 23 | run: | 24 | python -m pip install --upgrade pip 25 | pip install -r community/orgs/requirements.txt 26 | python community/orgs/org_user_management.py 27 | env: 28 | GH_TOKEN: ${{ secrets.GH_TOKEN }} 29 | INACTIVE_USER_MANAGEMENT_TAG_USERS: ${{ secrets.INACTIVE_USER_MANAGEMENT_TAG_USERS }} 30 | - name: Create Pull Request 31 | if: ${{ steps.uds.outputs.inactive_users_pr_description }} 32 | uses: peter-evans/create-pull-request@v5 33 | with: 34 | path: community 35 | add-paths: orgs/contributors.yml 36 | commit-message: Delete inactive users 37 | branch: delete-inactive-users 38 | title: 'Inactive users to be deleted' 39 | body: ${{ steps.uds.outputs.inactive_users_pr_description }} 40 | -------------------------------------------------------------------------------- /.github/workflows/org-management-check-prs.yml: -------------------------------------------------------------------------------- 1 | name: 'Check Github Organization Settings PRs' 2 | on: 3 | pull_request: 4 | paths: 5 | - 'orgs/*' 6 | - 'toc/TOC.md' 7 | - 'toc/working-groups/*.md' 8 | - '.github/workflows/org-management-check-prs.yml' 9 | jobs: 10 | org-config-generation-check: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/setup-python@v5 14 | with: 15 | python-version: 3.13 16 | - uses: actions/checkout@v4 17 | with: 18 | path: community 19 | - name: Generate github org configuration 20 | run: | 21 | python -m pip install --upgrade pip 22 | pip install -r community/orgs/requirements.txt 23 | python community/orgs/org_management.py -o orgs.out.yml -b branchprotection.out.yml 24 | -------------------------------------------------------------------------------- /.github/workflows/org-management-ci.yml: -------------------------------------------------------------------------------- 1 | name: 'Org Automation CI' 2 | on: 3 | pull_request: 4 | paths: 5 | - 'orgs/*.py' 6 | - 'orgs/requirements*' 7 | - 'orgs/pyproject.toml' 8 | - '.github/workflows/org-management-ci.yml' 9 | jobs: 10 | org-automation-tests: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/setup-python@v5 14 | with: 15 | python-version: 3.13 16 | - uses: actions/checkout@v4 17 | with: 18 | path: community 19 | - name: pip install 20 | run: | 21 | python -m pip install --upgrade pip 22 | pip install -r community/orgs/requirements.txt 23 | pip install -r community/orgs/requirements-dev.txt 24 | - name: flake8 and black 25 | run: | 26 | cd community/orgs 27 | python -m flake8 28 | - name: unit tests 29 | run: | 30 | cd community/orgs 31 | python -m unittest discover -s . 32 | -------------------------------------------------------------------------------- /.github/workflows/org-management-peribolos-dump.yml: -------------------------------------------------------------------------------- 1 | name: 'Dump Github Organization Settings' 2 | on: 3 | workflow_dispatch 4 | 5 | jobs: 6 | generate-peribolos-dump: 7 | runs-on: ubuntu-latest 8 | concurrency: 9 | group: peribolos 10 | services: 11 | ghproxy: 12 | image: rkoster/ghproxy 13 | options: >- 14 | --mount type=bind,source=/etc/passwd,target=/etc/passwd,readonly 15 | --mount type=bind,source=/etc/group,target=/etc/group,readonly 16 | ports: 17 | - 8888:8888 18 | volumes: 19 | - ${{ github.workspace }}/ghproxy-cache:/cache 20 | steps: 21 | - name: ghproxy-cache 22 | uses: actions/cache@v4 23 | with: 24 | path: ${{ github.workspace }}/ghproxy-cache 25 | key: ghproxy-cache-${{ github.run_number }} 26 | restore-keys: | 27 | ghproxy-cache- 28 | - uses: actions/checkout@v4 29 | with: 30 | fetch-depth: 0 # full clone so a PR can be created if needed 31 | path: community 32 | - name: write github private key 33 | run: | 34 | echo "${GH_PRIVATE_KEY}" > private_key 35 | echo "${GH_TOKEN}" > token 36 | env: 37 | GH_TOKEN: ${{ secrets.GH_TOKEN }} 38 | GH_PRIVATE_KEY: ${{ secrets.GH_PRIVATE_KEY }} 39 | - name: generate-peribolos-dump 40 | uses: docker://gcr.io/k8s-prow/peribolos 41 | with: 42 | entrypoint: /bin/sh 43 | # Switch back to app auth once following PR gets merged: https://github.com/kubernetes/test-infra/pull/24882 44 | # args: --dump-full --dump cloudfoundry --github-app-id=${{ secrets.GH_APP_ID }} --github-app-private-key-path=private_key > orgs/orgs.yml 45 | args: -c "/ko-app/peribolos --dump-full --dump cloudfoundry --github-endpoint http://ghproxy:8888 --github-token-path=token > community/orgs/orgs.yml" 46 | - name: Create Pull Request 47 | uses: peter-evans/create-pull-request@v5 48 | with: 49 | path: community 50 | add-paths: orgs/orgs.yml 51 | commit-message: Run peribolos -dump-full 52 | branch: peribolos-dump 53 | draft: true 54 | title: 'Sync orgs/orgs.yml with reality' 55 | body: | 56 | This PR contains a fresh peribolos dump. 57 | PR is intended for debugging. Don't merge as-is because parts of the cloudfoundry org configuration are generated from WG charters. 58 | -------------------------------------------------------------------------------- /.github/workflows/org-management.yml: -------------------------------------------------------------------------------- 1 | name: 'Sync Github Organization Settings' 2 | on: 3 | push: 4 | branches: 5 | - 'main' 6 | paths: 7 | - 'orgs/*' 8 | - 'toc/TOC.md' 9 | - 'toc/working-groups/*.md' 10 | - '.github/workflows/org-management.yml' 11 | schedule: 12 | - cron: '0 */12 * * *' 13 | 14 | jobs: 15 | peribolos: 16 | runs-on: ubuntu-latest 17 | concurrency: 18 | group: peribolos 19 | services: 20 | ghproxy: 21 | image: rkoster/ghproxy 22 | options: >- 23 | --mount type=bind,source=/etc/passwd,target=/etc/passwd,readonly 24 | --mount type=bind,source=/etc/group,target=/etc/group,readonly 25 | ports: 26 | - 8888:8888 27 | volumes: 28 | - ${{ github.workspace }}/ghproxy-cache:/cache 29 | steps: 30 | - name: ghproxy-cache 31 | uses: actions/cache@v4 32 | with: 33 | path: ${{ github.workspace }}/ghproxy-cache 34 | key: ghproxy-cache-${{ github.run_number }} 35 | restore-keys: | 36 | ghproxy-cache- 37 | - uses: actions/setup-python@v5 38 | with: 39 | python-version: 3.13 40 | - uses: actions/checkout@v4 41 | with: 42 | path: community 43 | - name: Generate github org configuration 44 | run: | 45 | python -m pip install --upgrade pip 46 | pip install -r community/orgs/requirements.txt 47 | python community/orgs/org_management.py -o orgs.out.yml -b branchprotection.out.yml 48 | - name: write github private key 49 | run: | 50 | echo "${GH_PRIVATE_KEY}" > private_key 51 | echo "${GH_TOKEN}" > token 52 | env: 53 | GH_TOKEN: ${{ secrets.GH_TOKEN }} 54 | GH_PRIVATE_KEY: ${{ secrets.GH_PRIVATE_KEY }} 55 | - name: peribolos 56 | id: peribolos 57 | uses: docker://gcr.io/k8s-prow/peribolos 58 | with: 59 | entrypoint: /ko-app/peribolos 60 | args: >- 61 | --confirm=true 62 | --github-endpoint http://ghproxy:8888 63 | --required-admins=thelinuxfoundation 64 | --min-admins=5 65 | --github-app-id=${{ secrets.GH_APP_ID }} 66 | --github-app-private-key-path=private_key 67 | --require-self=false 68 | --config-path=orgs.out.yml 69 | --fix-org 70 | --fix-org-members 71 | --fix-repos 72 | --fix-teams 73 | --fix-team-members 74 | --fix-team-repos 75 | --allow-repo-archival 76 | branchprotector: 77 | needs: peribolos 78 | runs-on: ubuntu-latest 79 | concurrency: 80 | group: peribolos 81 | services: 82 | ghproxy: 83 | image: rkoster/ghproxy 84 | options: >- 85 | --mount type=bind,source=/etc/passwd,target=/etc/passwd,readonly 86 | --mount type=bind,source=/etc/group,target=/etc/group,readonly 87 | ports: 88 | - 8888:8888 89 | volumes: 90 | - ${{ github.workspace }}/ghproxy-cache:/cache 91 | steps: 92 | - name: ghproxy-cache 93 | uses: actions/cache@v4 94 | with: 95 | path: ${{ github.workspace }}/ghproxy-cache 96 | key: ghproxy-cache-${{ github.run_number }} 97 | restore-keys: | 98 | ghproxy-cache- 99 | - uses: actions/setup-python@v5 100 | with: 101 | python-version: 3.13 102 | - uses: actions/checkout@v4 103 | with: 104 | path: community 105 | - name: Generate github org configuration 106 | run: | 107 | python -m pip install --upgrade pip 108 | pip install -r community/orgs/requirements.txt 109 | python community/orgs/org_management.py -o orgs.out.yml -b branchprotection.out.yml 110 | - name: write github private key 111 | run: | 112 | echo "${GH_PRIVATE_KEY}" > private_key 113 | echo "${GH_TOKEN}" > token 114 | env: 115 | GH_TOKEN: ${{ secrets.GH_TOKEN }} 116 | GH_PRIVATE_KEY: ${{ secrets.GH_PRIVATE_KEY }} 117 | - name: branchprotector 118 | id: branchprotector 119 | uses: docker://gcr.io/k8s-prow/branchprotector 120 | with: 121 | args: >- 122 | --confirm=true 123 | --github-endpoint http://ghproxy:8888 124 | --github-app-id=${{ secrets.GH_APP_ID }} 125 | --github-app-private-key-path=private_key 126 | --config-path=branchprotection.out.yml 127 | -------------------------------------------------------------------------------- /.github/workflows/project-sync.yml: -------------------------------------------------------------------------------- 1 | name: 'Sync working group project boards' 2 | 3 | on: 4 | schedule: 5 | - cron: '0 */1 * * *' 6 | 7 | jobs: 8 | configs: 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: actions/checkout@v4 12 | - id: matrix 13 | run: | 14 | echo "::set-output name=matrix::$(./orgs/generate_working_group_projects_sync_config.sh)" 15 | outputs: 16 | matrix: ${{ steps.matrix.outputs.matrix }} 17 | 18 | sync_projects: 19 | needs: configs 20 | runs-on: ubuntu-latest 21 | container: 22 | image: rkoster/github-multi-repo-project-card-sync 23 | 24 | strategy: 25 | fail-fast: false 26 | matrix: 27 | config: ${{ fromJson(needs.configs.outputs.matrix) }} 28 | 29 | steps: 30 | - name: write-config 31 | run: echo '${{ toJSON(matrix.config) }}' > config.json 32 | - name: github-projects-sync 33 | run: /root/sync --config config.json 34 | env: 35 | GITHUB_APP_ID: ${{ secrets.GH_APP_ID }} 36 | GITHUB_PRIVATE_KEY: ${{ secrets.GH_PRIVATE_KEY }} 37 | -------------------------------------------------------------------------------- /.github/workflows/remove-individual-access.yml: -------------------------------------------------------------------------------- 1 | name: 'Remove individual access to repos' 2 | on: 3 | push: 4 | branches: 5 | - main 6 | schedule: 7 | - cron: '0 */1 * * *' 8 | 9 | jobs: 10 | remove-individual-access-to-repos: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v4 14 | with: 15 | path: community 16 | - name: Remove individual access to repos 17 | env: 18 | GH_TOKEN: ${{ secrets.GH_TOKEN }} 19 | run: | 20 | set -e 21 | set -o pipefail 22 | 23 | ./community/toc/working-groups/parsable-working-groups.sh | jq -r .[].areas[].repositories[] | grep -E '^cloudfoundry/' | while read -r repo; do 24 | gh api "repos/${repo}/collaborators?affiliation=direct" | jq -r .[].login | while read -r user; do 25 | echo "remove ${user} from ${repo}" 26 | gh api -X delete "/repos/${repo}/collaborators/${user}" 27 | done 28 | done 29 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | toc/elections/2021/private.csv 3 | /.secrets 4 | .vscode 5 | __pycache__ 6 | orgs.out.yml 7 | branchprotection.out.yml 8 | /.idea -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Governance working group being set as owners for this repo for now. Assume 2 | # that a TOC group will take ownership once the TOC is bootstrapped. 3 | 4 | * @cloudfoundry/governance-wg -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Thank you for your interest in contributing to Cloud Foundry 2 | 3 | We try to tag issues that should be reasonable for a new contributor to take on with a [good first issue](https://github.com/search?q=org%3Acloudfoundry+org%3Acommunity+label%3A%22good+first+issue%22+state%3Aopen&type=Issues) label so you have somewhere to start. 4 | 5 | **How to contribute:** 6 | - Fork the repo you'd like to make a contribution to 7 | - Clone your fork to your local workstation 8 | - Create a new branch for the issue 9 | - Make the necessary changes on that branch 10 | - Commit and push to that branch 11 | - Make a Pull Request against the repo 12 | - Sign the Contributor Licensing Agreement, if you haven’t already 13 | 14 | All committers to a Cloud Foundry Foundation project must sign a Contributor License Agreement. 15 | To sign these documents and begin contributing, please [sign in to the EasyCLA app](https://corporate.v1.easycla.lfx.linuxfoundation.org/). 16 | Or, you’ll simply be prompted to do so when you put in your first Pull Request. 17 | 18 | If you’d like to have someone review the agreement before signing, you may download them here: 19 | - [Individual Contributor License Agreement](https://www.cloudfoundry.org/wp-content/uploads/icla.pdf) 20 | - [Corporate Contributor License Agreement](https://www.cloudfoundry.org/wp-content/uploads/ccla.pdf) 21 | 22 | **Where can I reach out to the team?** 23 | 24 | - _Want to report concerns/bugs?_ Create an issue on the affected repo. 25 | - _Usage issues/help?_ Reach out to us on [Slack](https://slack.cloudfoundry.org/) or our [cf-dev mailing list](https://lists.cloudfoundry.org/g/cf-dev/topics). 26 | - _Want to participate in deeper architectural discussions?_ Attend a relevant [working group meeting](https://github.com/cloudfoundry/community/blob/main/toc/working-groups/WORKING-GROUPS.md) or our monthly CAB call. 27 | 28 | You’ll find these listed on our [community calendar](https://www.cloudfoundry.org/community-calendar/). 29 | -------------------------------------------------------------------------------- /NOTICE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2020-Present CloudFoundry.org Foundation, Inc. All Rights Reserved. 2 | 3 | Licensed under the Apache License, Version 2.0 (the "License"); 4 | you may not use this file except in compliance with the License. 5 | You may obtain a copy of the License at 6 | 7 | http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | Unless required by applicable law or agreed to in writing, software 10 | distributed under the License is distributed on an "AS IS" BASIS, 11 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | See the License for the specific language governing permissions and 13 | limitations under the License. 14 | -------------------------------------------------------------------------------- /ORGS.md: -------------------------------------------------------------------------------- 1 | This document describes the set of Github Organizations that are overseen by the Cloud Foundry Foundation (CFF). 2 | 3 | 4 | ## Types of Github Organizations 5 | * *CFF Github Orgs* - This includes ALL Github Organizations that the CFF TOC 6 | oversees. 7 | 8 | * *CFF Managed Github Orgs* - This includes all Github organizations that are 9 | managed via the CFF TOC automation. 10 | 11 | ## List of CFF Github Organizations 12 | 13 | | Github Organization Name | Is it Managed? | 14 | |-----------------------------------------------------------|----------------| 15 | | [cloudfoundry](https://github.com/cloudfoundry) | Yes | 16 | | [openservicebrokerapi](https://github.com/openservicebrokerapi)| No | 17 | | [paketo-buildpacks](https://github.com/paketo-buildpacks) | No | 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | This repository holds a set of documents that govern the work of the Cloud Foundry Foundation (CFF), 2 | both the foundation itself and the technical communities that it supports. 3 | 4 | There are two categories of governace included: foundation and technical community. 5 | 6 | # Foundation Governance 7 | 8 | Changes to these policies and agreements require a vote of the CFF Governing Board. 9 | 10 | * [CFF Charter](governing-board/charter.md) - (Status: ACTIVE) - The charter 11 | for the CFF, included in the participation agreement that every member signs 12 | 13 | * [Foundation Governance](https://www.cloudfoundry.org/governance/) - (Status: ACTIVE) - Top level 14 | policies of the Cloud Foundry Foundation 15 | 16 | * [Code of Conduct](https://www.cloudfoundry.org/code-of-conduct/) - (Status: ACTIVE) - Code of Conduct 17 | governing all participation in the Cloud Foundry community 18 | 19 | # Technical Community Governance 20 | 21 | Changes to these documents require a vote (or consensus) of the Technical Oversight Committee (TOC). 22 | 23 | * [Principles](toc/PRINCIPLES.md) - (Status: INFORMATIONAL) - Core principles that inform the technical 24 | governance of the Cloud Foundry community 25 | 26 | * [Roles](toc/ROLES.md) - (Status: ACTIVE) - Description of the various technical community roles 27 | and the responsibilities, requirements, privileges and scope of each role 28 | 29 | * [Technical Oversight Committee](toc/TOC.md) - (Status: ACTIVE) - Technical governance structure and 30 | process 31 | 32 | * [Change Plan](toc/CHANGEPLAN.md) - (Status: DONE) - Plan for how to get from the community's current policies and practices to a new desired state 33 | 34 | The evolution of the Cloud Foundry Technical Community Governance is explained in this [talk](https://youtu.be/OBKsdVpFfyQ). 35 | 36 | ## Working Groups 37 | 38 | (Status: ACTIVE) 39 | 40 | The technical community's activities are structured into working groups by the TOC. For a listing of the 41 | active working groups, see [WORKING-GROUPS.md](toc/working-groups/WORKING-GROUPS.md). 42 | -------------------------------------------------------------------------------- /ci/docker/ghproxy/Dockerfile: -------------------------------------------------------------------------------- 1 | FROM gcr.io/k8s-prow/ghproxy 2 | VOLUME ["/cache"] 3 | ADD entrypoint.sh /entrypoint.sh 4 | RUN chmod +x /entrypoint.sh 5 | ENTRYPOINT ["/entrypoint.sh"] 6 | -------------------------------------------------------------------------------- /ci/docker/ghproxy/entrypoint.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | chown runner /cache 4 | 5 | su runner -p -s /bin/sh -c '/ko-app/ghproxy --legacy-disable-disk-cache-partitions-by-auth-header=false --cache-dir=/cache --cache-sizeGB=5 --log-level=info' 6 | -------------------------------------------------------------------------------- /elections/2021/TOC/README.md: -------------------------------------------------------------------------------- 1 | # 2021 CFF TOC Election Guide 2 | 3 | ## Overview 4 | 5 | Each year, the CFF technical community holds an election for open seats on the 6 | Technical Oversight Committee (TOC). The rules governing this election are set in the 7 | [CFF's project charter](../../../governing-board/charter.md) (See section 7(b) and 7(e) 8 | for the relevant details). 9 | 10 | This guide exists to serve as a guide to this year's election process. 11 | 12 | ## Schedule 13 | 14 | | Date | Event | 15 | | -------------------------- | ------------------------ | 16 | | May 11 | Announcement of Election (at least 4 weeks before results) | 17 | | May 11 through May 28 | Candidate nomination period (at least 2 weeks long and ending 2 weeks before results | 18 | | June 1 | Election Begins via email ballots (alow 2 work days to prepare election system) | 19 | | June 15 | Election Closes (at least 2 weeks after election begins) | 20 | | *June 17* | Announcement of Results (at least 2 work days after election ends) | 21 | 22 | ## Candidate Processes 23 | 24 | **Nominations** 25 | 26 | Every eligible voter can nominate candidates for the TOC, and we encourage you to do so. If you are 27 | eligible to serve on the TOC, you can self nominate! If you want to nominate someone else, do so as 28 | well! 29 | 30 | You can nominate someone for the TOC by [submitting an issue using this template](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=toc-candidate-nomination.md&title=TOC+Candidate+Nomination+for+%5BPerson+Name%5D). 31 | 32 | The deadline is May 28th to be nominated (and for the nominee to indicate acceptance). 33 | 34 | It is strongly recommended that you confirm that a nominee is interested and willing 35 | to accept the nomination prior to submitting the nomination issue. 36 | 37 | **Confirming Nominee Eligibility** 38 | 39 | Once a nomination is received, the CFF staff will contact the nominee to confirm acceptance 40 | of the nomination. If the nominee accepts, they will be added to the list of nominees at the bottom 41 | of this file. The nomination issue will be closed, noting if the nominee accepted or declined the 42 | nomination. 43 | 44 | ## Voting Process 45 | 46 | The election will be conducted using a time-limited [Condorcet](https://civs.cs.cornell.edu/rp.html) ranking 47 | on [CIVS](http://civs.cs.cornell.edu/) using the Schulze method. 48 | 49 | Voters will receive an email with a ballot link. Voters will have until the end of the election cycle 50 | to submit their ballot. 51 | 52 | ## Election Results 53 | 54 | The newly elected body will be announced via cf-dev@lists.cloudfoundry.org on 17 Jun, 2021. 55 | 56 | Following the announcement, the raw voting results and winners will be published. 57 | 58 | ## Nominees 59 | 60 | | Name | Organization/Company | GitHub | 61 | |:----------:|:--------------------:|:--------:| 62 | | Name | Employer | [@githubid](https://github.com/githubid) | 63 | -------------------------------------------------------------------------------- /elections/2021/TOC/ballots.csv: -------------------------------------------------------------------------------- 1 | Eric Malm,Andrew Edgar,David Stevenson,Beyhan Veli,Jan von Loewenstein,Stephan Merker,Daniel Vaughan,Lee Porte 2 | 2,3,1,4,4,3,3,3 3 | 1,5,8,4,2,3,8,8 4 | 3,4,5,1,2,8,7,6 5 | 4,8,8,4,1,1,8,4 6 | 1,8,2,8,8,3,8,8 7 | 1,2,3,6,4,7,8,5 8 | 1,4,2,5,3,8,8,8 9 | 3,1,2,4,5,6,7,8 10 | 2,8,8,3,8,8,8,1 11 | 2,8,1,4,3,5,8,6 12 | 2,8,1,8,8,8,8,3 13 | 1,8,2,5,3,4,7,6 14 | 2,5,7,2,5,1,7,4 15 | 4,7,6,3,2,1,8,5 16 | 4,6,5,2,3,1,8,7 17 | 1,8,5,6,3,2,6,4 18 | 1,8,2,7,3,6,4,5 19 | 5,6,7,3,2,1,8,4 20 | 1,2,3,8,6,5,7,4 21 | 2,3,1,5,4,8,8,6 22 | 1,4,1,6,2,5,8,3 23 | 3,2,8,8,5,6,4,1 24 | 1,8,1,8,8,8,8,8 25 | 1,8,2,8,8,8,8,8 26 | 2,1,1,3,4,5,7,6 27 | 2,4,1,3,5,8,6,8 28 | 1,4,7,5,4,3,8,2 29 | 3,4,8,8,2,5,8,1 30 | 1,8,2,3,4,5,8,8 31 | 2,5,1,7,3,6,8,4 32 | 1,8,2,8,8,8,8,8 33 | 2,4,7,3,5,1,8,6 34 | 4,5,6,3,2,1,8,7 35 | 4,6,8,3,7,1,5,2 36 | 8,1,7,6,6,5,1,3 37 | 1,5,2,4,4,4,5,3 38 | 1,3,2,6,4,7,8,5 39 | 1,3,2,8,8,8,8,4 40 | 1,8,2,5,3,8,8,8 41 | 2,8,1,8,8,8,8,8 42 | 1,3,2,8,8,8,8,8 43 | 1,3,2,6,4,5,8,7 44 | 8,1,1,6,5,1,8,1 45 | 1,4,2,4,4,4,4,3 46 | 2,8,1,8,8,8,8,3 47 | 2,8,1,4,3,7,5,7 48 | 1,4,7,5,3,8,6,2 49 | 1,8,2,8,3,4,8,5 50 | 2,4,2,5,3,5,4,1 51 | 1,5,2,8,3,8,8,4 52 | 2,1,8,7,3,5,4,6 53 | 8,8,8,1,2,2,8,8 54 | 4,5,8,3,1,2,7,6 55 | 1,3,8,2,4,5,6,7 56 | 4,6,5,3,2,1,8,7 57 | 1,5,2,3,7,6,8,4 58 | 1,8,2,3,3,3,7,6 59 | 1,7,2,5,3,4,8,6 60 | 8,8,8,1,1,1,8,8 61 | 1,8,2,7,3,6,4,5 62 | 1,8,3,8,3,8,4,2 63 | 2,3,1,6,8,7,4,5 64 | 1,8,2,7,3,6,5,4 65 | 1,5,3,8,7,2,6,4 66 | 1,8,1,2,3,2,8,2 67 | 2,1,5,7,3,8,4,6 68 | 8,8,8,8,8,8,8,8 69 | 3,6,5,1,4,2,8,7 70 | 1,8,1,3,3,3,8,6 71 | 4,6,5,3,1,2,7,8 72 | 1,8,1,8,8,8,8,2 73 | 1,3,1,4,2,4,8,8 74 | 1,2,1,6,3,7,4,5 75 | 1,5,1,2,2,3,4,3 76 | 2,3,1,5,7,6,8,4 77 | 5,8,4,1,3,2,6,7 78 | 2,4,1,3,4,4,8,8 79 | 1,8,2,4,5,3,6,6 80 | 1,2,7,8,4,6,5,3 81 | 1,7,2,4,5,6,8,3 82 | 1,5,2,7,4,6,8,3 83 | 6,4,2,4,4,5,7,7 84 | 1,8,2,4,3,5,6,7 85 | 4,5,8,1,3,2,6,7 86 | 1,6,2,5,4,3,7,8 87 | 1,4,2,8,5,6,7,3 88 | 3,5,2,1,2,3,8,6 89 | 1,4,2,7,6,3,8,5 90 | 4,7,5,3,2,1,8,6 91 | 8,2,1,3,8,4,8,8 92 | 2,5,1,4,3,8,8,8 93 | 8,8,8,7,6,1,8,8 94 | 8,8,8,1,1,1,8,8 95 | 1,6,2,3,5,7,4,8 96 | 2,3,8,6,3,1,4,5 97 | 1,5,2,6,3,7,8,4 98 | 1,1,2,2,1,1,8,8 99 | 6,4,5,1,3,2,8,7 100 | -------------------------------------------------------------------------------- /elections/2021/TOC/results.md: -------------------------------------------------------------------------------- 1 | # 2021 CFF Technical Oversight Committee Election Results 2 | 3 | Many thanks to everyone who took the time to register and vote in the first Cloud Foundry Foundation annual election for our newly forming Technical Oversight Committee (TOC). I also extend my deep thanks to all of the nominees who agreed to run in the election. Overall, our community’s participation in this election process was outstanding (especially given that this was our first time doing this!) 4 | 5 | And with that preamble, I’m pleased to announce our first CFF Technical Oversight Committee will be: 6 | 7 | * Eric Malm (VMware) 8 | * David Stevenson (VMware) 9 | * Jan von Loewenstein (SAP) 10 | * Stephan Merker (SAP) 11 | * Lee Porte (GOV.UK) 12 | 13 | Congratulations to Eric, David, Jan, Stephan and Lee! I’m looking forward to working with you to get the TOC up and running. 14 | 15 | ## Details 16 | 17 | One of the [primary principles](https://github.com/cloudfoundry/community/blob/main/toc/PRINCIPLES.md) that our technical governance process is based on is transparency. That applies to the election process and results themselves, with the only exception being that ballot records are anonymous. 18 | 19 | With that in mind, here are the election details: 20 | 21 | Election Supervisor: Chip Childers 22 | 23 | Announced end of poll: June 15, 2021 24 | 25 | Actual time poll closed: 6/15/2021, 8:07:44 PM ET 26 | 27 | Private poll (125 authorized voters) 28 | 29 | Actual votes cast: 98 30 | 31 | Complete results of the election, using the Schulze rules for Condorcet completion, are: 32 | 33 | 1. Eric Malm (Condorcet winner: wins contests with all other choices) 34 | 2. David Stevenson loses to Eric Malm by 62–22 35 | 3. Jan von Loewenstein loses to Eric Malm by 73–22, loses to David Stevenson by 60–34 36 | 4. Stephan Merker loses to Eric Malm by 70–25, loses to Jan von Loewenstein by 46–31 37 | 5. Beyhan Veli loses to Eric Malm by 72–23, loses to Stephan Merker by 42–35 38 | 6. Lee Porte loses to Eric Malm by 83–8, loses to Beyhan Veli by 48–41 39 | 7. Andrew Edgar loses to Eric Malm by 82–10, loses to Lee Porte by 43–41 40 | 8. Daniel Vaughan loses to Eric Malm by 90–1, loses to Andrew Edgar by 58–14 41 | 42 | Our TOC rules for a maximum of 2 TOC members from the same employer must be applied to these results, placing Lee Porte on the TOC instead of Beyhan Veli. 43 | 44 | Eric and David were the top two nominees of the group, meaning that both of them will have the full two year TOC member term. Jan, Stephan and Lee will each have a one year term, and their seats on the TOC will be up for election again in 2022. Keep in mind that this difference in term lengths only applies to this first election. In 2022, those three TOC seats will be elected for the standard TOC member term of two years. Of course, Jan, Stephan and Lee will be more than welcome to run in 2022. 45 | 46 | Records of all cast ballots are available in [CSV format here](ballots.csv). 47 | 48 | ## 2022-05-17 Amendment 49 | 50 | In the TOC meeting on May 17th, 2022, the TOC decided it would be more equitable to distribute the seats with the 2021-2023 terms evenly between the VMware and the SAP representatives. The TOC also decided to allocate the 2-year seat to Stephan Merker, since Jan von Loewenstein intends not to run for a continued position on the TOC after the 2021-2022 term. 51 | -------------------------------------------------------------------------------- /elections/2022/TOC/README.md: -------------------------------------------------------------------------------- 1 | # 2022 CFF TOC Election Guide 2 | 3 | 4 | ## Overview 5 | 6 | 7 | Each year, the CFF technical community holds an election for open seats on the 8 | Technical Oversight Committee (TOC). The rules governing this election are set in the 9 | [CFF's project charter](../../../governing-board/charter.md) (See section 7(b) and 7(e) 10 | for the relevant details). 11 | 12 | 13 | This guide exists to serve as a guide to this year's election process. 14 | 15 | 16 | ## Schedule 17 | 18 | - **May 18**: Election is announced and candidate nomination period begins 19 | - **June 2, 5:00 pm PDT**: Candidate nomination period ends 20 | - **June 2, 11:59 pm PDT**: Election begins 21 | - **June 17, 11:59 pm PDT**: Election ends 22 | - **June 22**: Announcement of results 23 | 24 | 25 | ## Candidate Processes 26 | 27 | 28 | ### Nominations 29 | 30 | 31 | Every eligible voter can nominate candidates for the TOC, and we encourage you to do so. If you are 32 | eligible to serve on the TOC, you can self nominate! If you want to nominate someone else, do so as 33 | well! 34 | 35 | 36 | You can nominate someone for the TOC by [submitting an issue using this template](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=toc-candidate-nomination.md&title=TOC+Candidate+Nomination+for+%5BPerson+Name%5D). 37 | 38 | 39 | The deadline is June 2nd to be nominated (and for the nominee to indicate acceptance). 40 | 41 | 42 | It is strongly recommended that you confirm that a nominee is interested and willing 43 | to accept the nomination prior to submitting the nomination issue. 44 | 45 | 46 | ### Confirming Nominee Eligibility 47 | 48 | 49 | Once a nomination is received, the CFF staff will contact the nominee to confirm acceptance 50 | of the nomination. If the nominee accepts, they will be added to the list of nominees at the bottom 51 | of this file. The nomination issue will be closed, noting if the nominee accepted or declined the 52 | nomination. 53 | 54 | 55 | ## Voting Process 56 | 57 | 58 | The 2022 TOC election will be conducted using a [CFF-managed instance](https://elections.cloudfoundry.org) of [Elekto](https://elekto.dev), a CNCF infrastructure project 59 | that implements Condorcet ranked-choice voting using the Schulze method. Elekto relies on GitHub 60 | for user identity and authentication, which better matches how members interact with the Cloud 61 | Foundry community on a day-to-day basis than the email identity that the [Condorcet Internet Voting 62 | Service](https://civs1.civs.us/) requires. 63 | 64 | If Elekto fails to recognize you as eligible to vote in this election even though you believe you 65 | should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2022---TOC/exception) or [via an issue on the 66 | community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-toc-election.md&title=Request+to+be+an+elector+for+TOC+election). 67 | 68 | Once the official election period starts, you will be able to rank the candidates in your preferred 69 | order and submit your ballot. You may set a password on your ballot, which is required to change 70 | your ballot later within the election period. Once the election period ends, all ballots are final. 71 | 72 | All ballot data for Elekto is stored on a database managed by the CFF staff, and is not shared with 73 | third parties. Individual ballot data is encrypted, and ballot data can be retrieved only in 74 | aggregate form. 75 | 76 | 77 | ## Election Results 78 | 79 | 80 | The newly elected body will be announced via cf-dev@lists.cloudfoundry.org on 22 Jun, 2022. 81 | 82 | 83 | Following the announcement, the voting results and winners will be published. 84 | 85 | 86 | ## Nominees 87 | 88 | 89 | | Name | Organization/Company | GitHub | Nomination Statement | 90 | |:----------:|:--------------------:|:--------:| :-------------------: | 91 | | Peter Burkholder | Cloud.gov | [@pburkholder](https://github.com/pburkholder) | [#293](https://github.com/cloudfoundry/community/issues/293) | 92 | | Andy Hunt | Gov.uk | [@AP-Hunt](https://github.com/AP-Hunt) | [#281](https://github.com/cloudfoundry/community/issues/281) 93 | | Ruben Koster | VMware | [@rkoster](https://github.com/rkoster) | [#287](https://github.com/cloudfoundry/community/issues/287) | 94 | | Beyhan Veli | SAP | [@beyhan](https://github.com/beyhan) | [#285](https://github.com/cloudfoundry/community/issues/285) | 95 | -------------------------------------------------------------------------------- /elections/2022/TOC/ballots.csv: -------------------------------------------------------------------------------- 1 | AP-Hunt,pburkholder,rkoster,beyhan 2 | 4,3,1,2 3 | 4,3,2,1 4 | 2,4,3,1 5 | 4,4,2,1 6 | 4,3,1,2 7 | 4,4,2,1 8 | No opinion,No opinion,2,1 9 | 1,4,2,3 10 | 4,4,1,2 11 | 2,3,1,4 12 | 3,4,2,1 13 | 1,2,3,4 14 | 3,2,1,4 15 | 4,2,3,1 16 | 4,3,1,2 17 | No opinion,No opinion,1,No opinion 18 | 2,3,1,4 19 | 3,4,2,1 20 | 3,4,1,2 21 | No opinion,No opinion,No opinion,1 22 | 3,4,1,2 23 | 1,2,3,4 24 | 1,2,3,4 25 | No opinion,No opinion,1,2 26 | 4,3,1,2 27 | 4,4,2,1 28 | 2,3,1,4 29 | 2,3,4,1 30 | 2,1,3,No opinion 31 | 2,1,4,3 32 | 2,3,1,4 33 | 2,4,3,1 34 | 3,2,1,4 35 | 4,3,1,2 36 | 4,3,1,2 37 | 3,2,1,4 38 | 3,4,2,1 39 | 3,1,4,2 40 | 3,4,2,1 41 | 2,3,1,4 42 | No opinion,No opinion,1,No opinion 43 | 3,2,4,1 44 | 3,4,2,1 45 | 2,No opinion,1,3 46 | 4,3,1,2 47 | No opinion,No opinion,4,No opinion 48 | 2,3,1,4 49 | 4,4,4,1 50 | No opinion,No opinion,2,1 51 | 1,2,4,3 52 | 2,No opinion,1,2 53 | 3,4,2,1 54 | 4,1,3,2 55 | 4,4,2,1 56 | 2,4,3,1 57 | 4,4,4,1 58 | 4,3,1,2 59 | 3,2,1,4 60 | 2,3,1,4 61 | 3,4,1,2 62 | -------------------------------------------------------------------------------- /elections/2022/TOC/candidate-AP-Hunt.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Andy Hunt 3 | ID: AP-Hunt 4 | info: 5 | - employer: Government Digital Service (GOV.UK) 6 | - slack: Andy Hunt 7 | - github: AP-Hunt 8 | ------------------------------------------------------------- 9 | 10 | Nomination Statement: Andy Hunt is technical lead of the GOV.UK PaaS team. Andy is an active participant in the community particularly within the government space. His core focus is around maintaining the excellence of the end user experience, he has made several enhancements in this area and continues to engage in making things better for all of our end users. He is keen to see the community grow and move from strength to strength and has a desire to ensure that there is the right environment for this to happen. 11 | 12 | -------------------------------------------------------------------------------- /elections/2022/TOC/candidate-beyhan.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Beyhan Veli 3 | ID: beyhan 4 | info: 5 | - employer: SAP 6 | - slack: beyhan 7 | - github: beyhan 8 | ------------------------------------------------------------- 9 | 10 | Nomination Statement: Beyhan has been active in the Cloud Foundry community for the past 7+ years. He started to contribute to the Cloud Foundry community as member of the BOSH team at SAP. His focus areas have been BOSH in general, BOSH DNS, BOSH monitoring, the BOSH command line interface, and bosh-deployment. Additionally, he actively helped people via the community BOSH slack channel and gave sessions about BOSH at CF Summit and CF Operators SIG . E.g. in 2020, he did a CF summit session titled "A Journey Through BOSH and BOSH DNS Monitoring" ([https://sched.co/fDVn](https://sched.co/fDVn), [https://youtu.be/jpnMKWKFhT0](https://youtu.be/jpnMKWKFhT0)). 11 | 12 | Since one year, Beyhan has taken on a broader role at SAP and is now also looking into other areas of Cloud Foundry like the Cloud Controller and general topics from a Cloud Foundry developer experience perspective. In the CF Community, Beyhan is technical lead in the Foundational Infrastructure working group and acted as the co-chair for the CF Summit 2021 "Behind the Curtain" track. 13 | -------------------------------------------------------------------------------- /elections/2022/TOC/candidate-pburkholder.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Peter Burkholder 3 | ID: pburkholder 4 | info: 5 | - employer: Cloud.gov 6 | - slack: pburkholder 7 | - github: pburkholder 8 | ------------------------------------------------------------- 9 | 10 | Nomination Statement: Peter Burkholder is the Security and Compliance Lead of the cloud.gov team. Peter has been a key anchor within the public sector CF user space for a significant number of years, He is in regular contact with public sector CF operators and end users at a global level. He brings a security and compliance drive to CF, that has not previously been a focus of the technical side of the foundation. His recent focus has been on highlighting SBOMs and SLSA compliance to the TOC and how this could work across the different working groups. 11 | -------------------------------------------------------------------------------- /elections/2022/TOC/candidate-rkoster.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Ruben Koster 3 | ID: rkoster 4 | info: 5 | - employer: VMware 6 | - slack: rkoster 7 | - github: rkoster 8 | ------------------------------------------------------------- 9 | 10 | Nomination Statement: Ruben has been a fantastic community player and contributor across many organizations. He's essentially playing a supporting member of the TOC right now, helping us do a lot of technology behind setting up working groups and teams. He's a natural leader, willing to make difficult decisions and move forward when needed. 11 | -------------------------------------------------------------------------------- /elections/2022/TOC/election.yaml: -------------------------------------------------------------------------------- 1 | name: 2022 CFF Technical Oversight Committee election 2 | organization: Cloud Foundry Foundation 3 | start_datetime: 2022-06-03 06:59:00 # 11:59 pm PDT, 02 Jun 2022 4 | end_datetime: 2022-06-18 06:59:00 # 11:59 pm PDT, 17 Jun 2022 5 | no_winners: 3 6 | allow_no_opinion: True 7 | delete_after: True 8 | show_candidate_fields: 9 | - employer 10 | - github 11 | - slack 12 | election_officers: 13 | - christopherclark 14 | - ramiyengar 15 | - sgreenberg 16 | - emalm 17 | - stephanme 18 | eligibility: Members of the Cloud Foundry organization with 25 or more contributions in the last year may vote. See [the voter eligibility section](https://github.com/cloudfoundry/community/blob/main/toc/TOC.md#community-eligibility-to-vote-in-toc-elections) for more information. 19 | exception_description: If you feel you are eligible to vote but are not represented in the list of voters, please request an exception to allow you to vote via the Elekto application. 20 | exceptions_due: 2022-06-15 06:59:00 # 11:59 pm PT, 14 Jun 2022 21 | -------------------------------------------------------------------------------- /elections/2022/TOC/election_desc.md: -------------------------------------------------------------------------------- 1 | The role of this election is to fill the three (3) seats due for election this year on the Cloud Foundry Foundation TOC. The elected members will serve two (2) year terms. 2 | This is a brief summary of the election; for more details, such as how to become a candidate, [see the README](https://github.com/cloudfoundry/community/tree/main/elections/2022/TOC#readme). 3 | 4 | ## Eligibility 5 | 6 | All contributors with 25 or more contributions to any Cloud Foundry Foundation project over the last year are eligible to vote. You will see either ELIGIBLE or NOT ELIGIBLE at the top of this screen. If Elekto fails to recognize you as eligible to vote in this election even though you believe you should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2022---TOC/exception) or via an issue on the community repository. The deadline for filing exceptions is June 14th, 11:59 pm PT. 7 | 8 | 9 | ### Schedule 10 | 11 | - **May 18**: Election is announced and candidate nomination period begins 12 | - **June 2, 5:00 pm PDT**: Candidate nomination period ends 13 | - **June 2, 11:59 pm PDT**: Election begins 14 | - **June 17, 11:59 pm PDT**: Election ends 15 | - **June 22**: Announcement of results 16 | 17 | 18 | ## Changing Your Vote 19 | 20 | With Elekto, you may revoke and re-cast your ballot until the election deadline of June 17th. To do so, set a passphrase when you cast your ballot; as long as you have that passphrase, you may re-cast your ballot by returning to the site. 21 | -------------------------------------------------------------------------------- /elections/2022/TOC/results.md: -------------------------------------------------------------------------------- 1 | # 2022 CFF Technical Oversight Committee Election Results 2 | 3 | Many thanks to all the nominees and everyone who voted in the election. 4 | 5 | I’m pleased to announce our new TOC members will be: 6 | 7 | * Ruben Koster (VMware) 8 | * Beyhan Veli (SAP) 9 | * Andy Hunt (GOV.UK) 10 | 11 | They'll be joining Eric Malm (VMware) and Stephan Merker (SAP), whose seats will be up for election next year. 12 | 13 | Congratulations to Ruben, Beyhan and Andy! 14 | 15 | ## Details 16 | 17 | Actual votes cast: 60 18 | 19 | Complete results of the election, using the Schulze rules for Condorcet completion, are: 20 | 21 | 1. Ruben Koster 22 | 2. Beyhan Veli 23 | 3. Andy Hunt 24 | 4. Peter Burkholder 25 | 26 | Records of all cast ballots are available in [CSV format here](https://github.com/cloudfoundry/community/blob/main/elections/2022/TOC/ballots.csv). 27 | -------------------------------------------------------------------------------- /elections/2023/Paketo-SC/ballots.csv: -------------------------------------------------------------------------------- 1 | dmikusa,ForestEckhardt,loewenstein 2 | 2,3,1 3 | 1,2,3 4 | 2,1,3 5 | 1,1,1 6 | 1,2,3 7 | 3,1,2 8 | 3,3,3 9 | 3,2,1 10 | 3,2,1 11 | 2,1,3 12 | 1,2,3 13 | 3,2,1 14 | 2,1,3 15 | 1,2,3 16 | 1,1,2 17 | 1,2,3 18 | 2,1,3 19 | 3,1,2 20 | 2,3,1 21 | -------------------------------------------------------------------------------- /elections/2023/Paketo-SC/candidate-ForestEckhardt.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Forest Eckhardt 3 | 4 | ID: ForestEckhardt 5 | 6 | info: 7 | - employer: VMware 8 | - slack: feckhardt 9 | - github: ForestEckhardt 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: I have been working on the Paketo Buildpacks project since its inception. I am maintainer of several language subteams I am heavily invested in the Paketo community as a whole! I would love to be able to have a leading role in shaping this project going forward. 13 | -------------------------------------------------------------------------------- /elections/2023/Paketo-SC/candidate-dmikusa.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Daniel Mikusa 3 | 4 | ID: dmikusa 5 | 6 | info: 7 | - employer: N/A - Independent 8 | - slack: dmikusa 9 | - github: dmikusa 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: As a current member of the Paketo Steering Committee, it has been a privilege to help the project grow and mature. I am seeking a nomination so that I can continue this effort. I believe we can continue to grow the project by listening to our users, by fostering an open and welcoming community, and by mentoring those that want to contribute to the project. If re-elected, those will be my areas of focus. 13 | -------------------------------------------------------------------------------- /elections/2023/Paketo-SC/candidate-loewenstein.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Jan von Löwenstein 3 | 4 | ID: loewenstein 5 | 6 | info: 7 | - employer: SAP SE 8 | - slack: loewenstein 9 | - github: loewenstein 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: I have been active in the Cloud Foundry community (as Bosh maintainer and later founding TOC member) since 2015. My team has been looking into Paketo buildpacks since around 2019 and we ramped up our involvement quite a bit since 2022 / 2023 with currently three contributors. 13 | Managing the backlog of my team, I speak a lot with buildpack users. At the same time I believe I still hold enough technical grasp to be able to translate between requirements and technical project direction. 14 | -------------------------------------------------------------------------------- /elections/2023/Paketo-SC/election.yaml: -------------------------------------------------------------------------------- 1 | name: 2023 Paketo Buildpacks Steering Committee election 2 | organization: Cloud Foundry Foundation 3 | start_datetime: 2023-06-02 06:59:00 # 11:59 pm PDT, 01 Jun 2023 4 | end_datetime: 2023-06-17 06:59:00 # 11:59 pm PDT, 16 Jun 2023 5 | no_winners: 3 6 | allow_no_opinion: True 7 | delete_after: True 8 | show_candidate_fields: 9 | - employer 10 | - github 11 | - slack 12 | election_officers: 13 | - christopherclark 14 | - emalm 15 | - dmikusa 16 | - sgreenberg 17 | eligibility: Any individual who has contributed to Paketo Buildpacks in the twelve months prior to the election is eligible to vote in the Steering Committee election. Each election cycle, an initial set of voters will be identified through automated reporting. Any individual who has at least 10 measurable contributions in the last 12 months will be automatically added to the eligible voter list. 18 | exception_description: If you feel you are eligible to vote but are not represented in the list of voters, please request an exception to allow you to vote via the Elekto application. 19 | exception_due: 2023-06-14 06:59:00 # 11:59 pm PT, 13 Jun 2023 20 | -------------------------------------------------------------------------------- /elections/2023/Paketo-SC/election_desc.md: -------------------------------------------------------------------------------- 1 | The role of this election is to fill the three (3) seats due for election this year on the Paketo Buildpacks Steering Committee. The two nominees who recieve the most votes will serve two (2) year terms, and the nominee who recieves the third most votes will serve a one (1) year term. In subsequent elections, all terms will be for two (2) years. This is a brief summary of the election; for more details, such as how to become a candidate, [see the README](https://github.com/cloudfoundry/community/tree/main/elections/2023/Paketo#readme). 2 | 3 | ## Eligibility 4 | 5 | Any individual who has contributed to Paketo Buildpacks in the twelve months prior to the election is eligible to vote in the Steering Committee election. You will see either ELIGIBLE or NOT ELIGIBLE at the top of this screen. If Elekto fails to recognize you as eligible to vote in this election even though you believe you should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2023---Paketo-SC/exception) or [via an issue on the community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-paketo-buildpacks-sc-election.md&title=Request+to+be+an+elector+for+Paketo+Steering+Committee+election). The deadline for filing exceptions is June 13th, 11:59 pm PT. 6 | 7 | ## Schedule 8 | 9 | May 18: Election is announced and candidate nomination period begins 10 | June 1, 5:00 pm PDT: Candidate nomination period ends 11 | June 1, 11:59 pm PDT: Election begins 12 | June 16, 11:59 pm PDT: Election ends 13 | June 20: Announcement of results 14 | 15 | ## Changing Your Vote 16 | 17 | With Elekto, you may revoke and re-cast your ballot until the election deadline of June 16th. To do so, set a passphrase when you cast your ballot; as long as you have that passphrase, you may re-cast your ballot by returning to the site. 18 | -------------------------------------------------------------------------------- /elections/2023/Paketo-SC/results.md: -------------------------------------------------------------------------------- 1 | # 2023 Paketo Steering Committee Election Results 2 | 3 | Many thanks to all the nominees and everyone who voted in the election! 4 | 5 | I’m pleased to announce our newly elected Steering Committee will consist of: 6 | 7 | * Forest Eckhardt (VMware) - 2 year term 8 | * Daniel Mikusa (NA - Independent) - 2 year term 9 | * Jan von Löwenstein (SAP SE) - 1 year term 10 | 11 | Congratulations to Forest, Daniel, and Jan! 12 | 13 | ## Details 14 | 15 | Actual votes cast: 19 16 | 17 | Complete results of the election, using the Schulze rules for Condorcet completion, are: 18 | 19 | * Forest Eckhardt 20 | * Daniel Mikusa 21 | * Jan von Löwenstein 22 | 23 | Records of all cast ballots are available in [CSV format here](https://github.com/cloudfoundry/community/blob/main/elections/2023/Paketo-SC/ballots.csv). 24 | -------------------------------------------------------------------------------- /elections/2023/Paketo-SC/voters.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | eligible_voters: 3 | - AidanDelaney 4 | - ajdergute 5 | - anthonydahanne 6 | - arjun024 7 | - Azbesciak 8 | - BarDweller 9 | - bbegw 10 | - belfo 11 | - bjongbloedt 12 | - blaenk 13 | - brayanhenao 14 | - c0d1ngm0nk3y 15 | - cforce 16 | - ChuckQuinnIV 17 | - conzetti 18 | - cz4rny 19 | - dashaun 20 | - davidmirror-ops 21 | - dmikusa 22 | - dpacheconr 23 | - dvigueras 24 | - eddumelendez 25 | - effulgentsia 26 | - ekcasey 27 | - emrekaratas06 28 | - engine-workflow 29 | - fg-j 30 | - fgrehm 31 | - findajay 32 | - ForestEckhardt 33 | - francescopersico 34 | - gkwan-ibm 35 | - goafabric 36 | - gudatcomputers 37 | - hibell 38 | - hovancik 39 | - imitbn 40 | - jansu76 41 | - jerzykrlkroche 42 | - jghiloni 43 | - johnkors 44 | - johnnyr0x 45 | - joshuatcasey 46 | - jpena-r7 47 | - kevin-ortega 48 | - kingdonb 49 | - kiranpatel11 50 | - kulhadia 51 | - loewenstein 52 | - makeavish 53 | - maliksalman 54 | - matejvasek 55 | - matthewmcnew 56 | - mgorsk1 57 | - mhdawson 58 | - mheath 59 | - modulo11 60 | - mstoodle 61 | - mterrel 62 | - mucsi96 63 | - musaffa 64 | - oceanicpanda 65 | - pacostas 66 | - pbusko 67 | - PerfectSlayer 68 | - peterjkirby 69 | - phil9909 70 | - pivotal-david-osullivan 71 | - pmbanugo 72 | - robdimsdale 73 | - ryanmoran 74 | - samj1912 75 | - SaschaSchwarze0 76 | - SchillingSebastian 77 | - scottfrederick 78 | - sdeleuze 79 | - semmet95 80 | - sgaist 81 | - sophiewigmore 82 | - sovereignstack 83 | - srisek 84 | - thitch97 85 | - ThomasVitale 86 | - TianMing2018 87 | - till 88 | - TisVictress 89 | - TomBeckett 90 | - ttys3 91 | - tuckeremulls 92 | - uqix 93 | - voor 94 | - xuan-nguyen-swe 95 | - zhoufenqin 96 | -------------------------------------------------------------------------------- /elections/2023/TOC/README.md: -------------------------------------------------------------------------------- 1 | # 2023 CFF TOC Election Guide 2 | 3 | 4 | ## Overview 5 | 6 | 7 | Each year, the CFF technical community holds an election for open seats on the 8 | Technical Oversight Committee (TOC). The rules governing this election are set in the 9 | [CFF's project charter](../../../governing-board/charter.md) (See section 7(b) and 7(e) 10 | for the relevant details). 11 | 12 | 13 | This guide exists to serve as a guide to this year's election process. 14 | 15 | 16 | ## Schedule 17 | 18 | - **May 18**: Election is announced and candidate nomination period begins 19 | - **June 1, 5:00 pm PDT**: Candidate nomination period ends 20 | - **June 1, 11:59 pm PDT**: Election begins 21 | - **June 16, 11:59 pm PDT**: Election ends 22 | - **June 20**: Announcement of results 23 | 24 | 25 | ## Candidate Processes 26 | 27 | 28 | ### Nominations 29 | 30 | 31 | Every eligible voter can nominate candidates for the TOC, and we encourage you to do so. If you are 32 | eligible to serve on the TOC, you can self nominate! If you want to nominate someone else, do so as 33 | well! 34 | 35 | 36 | You can nominate someone for the TOC by [submitting an issue using this template](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=toc-candidate-nomination.md&title=TOC+Candidate+Nomination+for+%5BPerson+Name%5D). 37 | 38 | 39 | The deadline is June 1nd to be nominated (and for the nominee to indicate acceptance). 40 | 41 | 42 | It is strongly recommended that you confirm that a nominee is interested and willing 43 | to accept the nomination prior to submitting the nomination issue. 44 | 45 | 46 | ### Confirming Nominee Eligibility 47 | 48 | 49 | Once a nomination is received, the CFF staff will contact the nominee to confirm acceptance 50 | of the nomination. If the nominee accepts, they will be added to the list of nominees at the bottom 51 | of this file. The nomination issue will be closed, noting if the nominee accepted or declined the 52 | nomination. 53 | 54 | 55 | ## Voting Process 56 | 57 | 58 | The 2023 TOC election will be conducted using a [CFF-managed instance](https://elections.cloudfoundry.org) of [Elekto](https://elekto.dev), a CNCF infrastructure project 59 | that implements Condorcet ranked-choice voting using the Schulze method. Elekto relies on GitHub 60 | for user identity and authentication, which better matches how members interact with the Cloud 61 | Foundry community on a day-to-day basis than the email identity that the [Condorcet Internet Voting 62 | Service](https://civs1.civs.us/) requires. 63 | 64 | Any individual who has contributed to CFF projects or technical working groups in the twelve months prior to the election is eligible to vote in the TOC election. Contributions include, but are not limited to, opening PRs, reviewing and commenting on PRs, opening and commenting on issues, writing design docs, commenting on design docs, participating in mailing list discussions and participating in working groups. 65 | 66 | If Elekto fails to recognize you as eligible to vote in this election even though you believe you 67 | should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2023---TOC/exception) or [via an issue on the 68 | community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-toc-election.md&title=Request+to+be+an+elector+for+TOC+election). 69 | 70 | Once the official election period starts, you will be able to rank the candidates in your preferred 71 | order and submit your ballot. You may set a password on your ballot, which is required to change 72 | your ballot later within the election period. Once the election period ends, all ballots are final. 73 | 74 | All ballot data for Elekto is stored on a database managed by the CFF staff, and is not shared with 75 | third parties. Individual ballot data is encrypted, and ballot data can be retrieved only in 76 | aggregate form. 77 | 78 | 79 | ## Election Results 80 | 81 | 82 | The newly elected body will be announced via cf-dev@lists.cloudfoundry.org on 20 Jun, 2022. 83 | 84 | 85 | Following the announcement, the voting results and winners will be published. 86 | 87 | 88 | ## Nominees 89 | 90 | 91 | | Name | Organization/Company | GitHub | Nomination Statement | 92 | |:----------:|:--------------------:|:--------:| :-------------------: | 93 | | Jesse Alford | NA - Independent | [@anEXPer](https://github.com/anEXPer) | [#612](https://github.com/cloudfoundry/community/issues/612) | 94 | | Amelia Downs | VMware | [@ameowlia](https://github.com/ameowlia) | [#614](https://github.com/cloudfoundry/community/issues/614) 95 | | Chris McGowan | Cloud.gov | [@ChrisMcGowan](https://github.com/ChrisMcGowan) | [#613](https://github.com/cloudfoundry/community/issues/613) | 96 | | Stephan Merker | SAP SE | [@stephanme](https://github.com/stephanme) | [#611](https://github.com/cloudfoundry/community/issues/611) | 97 | 98 | -------------------------------------------------------------------------------- /elections/2023/TOC/ballots.csv: -------------------------------------------------------------------------------- 1 | stephanme,anEXPer,ChrisMcGowan,ameowlia 2 | 2,3,4,1 3 | 3,2,4,1 4 | 1,4,3,2 5 | 3,4,1,2 6 | No opinion,2,No opinion,1 7 | 2,4,4,1 8 | 1,4,3,2 9 | 1,3,4,2 10 | 3,2,4,1 11 | No opinion,No opinion,1,No opinion 12 | 1,4,3,2 13 | 1,No opinion,No opinion,No opinion 14 | 1,3,4,2 15 | 2,No opinion,3,1 16 | 2,4,3,1 17 | 4,No opinion,No opinion,2 18 | 3,4,1,2 19 | No opinion,2,No opinion,1 20 | 2,4,3,1 21 | 2,4,3,1 22 | 3,2,4,1 23 | 2,4,4,1 24 | No opinion,2,3,1 25 | 2,3,4,1 26 | 4,2,3,1 27 | 1,No opinion,No opinion,2 28 | 4,3,2,1 29 | 1,4,3,2 30 | 3,4,1,2 31 | 1,4,3,2 32 | 4,2,3,1 33 | 2,4,3,1 34 | 2,No opinion,3,1 35 | 1,4,3,2 36 | 3,2,4,1 37 | 3,4,2,1 38 | 4,2,4,1 39 | No opinion,No opinion,1,No opinion 40 | 4,2,3,1 41 | 4,1,4,1 42 | 3,4,1,2 43 | 1,4,4,2 44 | 4,1,1,1 45 | 2,4,3,1 46 | 2,3,4,1 47 | 4,2,3,1 48 | 4,2,3,1 49 | 2,3,4,1 50 | 2,3,3,1 51 | 3,2,2,1 52 | 1,4,4,2 53 | 1,3,3,2 54 | 4,1,3,2 55 | 4,2,3,1 56 | 2,4,3,1 57 | 2,4,3,1 58 | 1,No opinion,No opinion,2 59 | 1,4,3,2 60 | 2,4,1,3 61 | 3,4,2,1 62 | 1,4,3,2 63 | 4,4,1,4 64 | 2,4,3,1 65 | 2,4,3,1 66 | 1,No opinion,2,2 67 | 1,2,4,3 68 | 1,No opinion,No opinion,3 69 | -------------------------------------------------------------------------------- /elections/2023/TOC/candidate-ChrisMcGowan.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Chris McGowan 3 | 4 | ID: ChrisMcGowan 5 | 6 | info: 7 | - employer: Cloud.gov 8 | - slack: cmcgowan 9 | - github: ChrisMcGowan 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: Chris is a senior engineer with cloud.gov, the U.S. government's primary public sector Cloud Foundry service. He's a seasoned Cloud Foundry engineer who has supported operations at GE Predix, Home Depot and for clients of Stark & Wayne. His open-source contributions include numerous repos at cloud.gov, various kits, including BOSH and CF App Autoscaler, for Genesis Community, and Shield, an open-source backup utility. 13 | 14 | I'm nominating Chris because the CFF and the TOC have benefited from public sector representation, as shown by the UK's Lee Porte and Andy Hunt. Chris is well-suited to carry on that tradition with his deep engineering knowledge coupled with an understanding of compliance and sustainability. He considers deeply the tradeoffs of engineering and architectural decisions, explains technical concepts well, and is a generous colleague. 15 | 16 | In all, he's ideally suited to help Cloud Foundry to continue to grow and thrive. 17 | -------------------------------------------------------------------------------- /elections/2023/TOC/candidate-ameowlia.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Amelia Downs 3 | 4 | ID: ameowlia 5 | 6 | info: 7 | - employer: VMware 8 | - slack: ameowlia 9 | - github: ameowlia 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: Amelia has been a stellar contributor and leader within the Cloud Foundry community since she joined it in 2016. Most recently, she has been serving as the Technical and Execution Lead for the Application Runtime Platform Working Group since its inception and has been instrumental in shaping the collaboration practices and healthy activity within that working group. 13 | 14 | She has also provided deep technical leadership and expertise within primarily the Networking and the Diego areas of the Cloud Foundry Application Runtime, driving forward substantial improvements to gorouter, container-to-container networking, TCP router, Envoy-based route integrity, NATS security, and dynamic application security groups, among other areas. She has deep empathy for the application developers, platform engineers, and security teams that Cloud Foundry serves and consistently keeps their needs and experiences in mind when developing effective solutions for them. 15 | 16 | Additionally, Amelia has been an engaging and effective communicator for the Cloud Foundry project, delivering excellent technical presentations at Cloud Foundry Summits and other events and serving as a model for clear and actionable messaging across the community. She also has experience contributing to other open-source projects, having spent several months participating in and contributing to the Golang project, and consequently has a thorough understanding of how open-source projects can be effective in cultivating healthy community participation. 17 | 18 | Overall, Amelia would be an excellent member of the CFF TOC, and I cannot think of a better representative of our community than her. 19 | -------------------------------------------------------------------------------- /elections/2023/TOC/candidate-anEXPer.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Jesse Alford 3 | 4 | ID: anEXPer 5 | 6 | info: 7 | - employer: NA - Independent 8 | - slack: anEXPer 9 | - github: anEXPer 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: This being a self nomination, I'll speak in the first-person. I've worked on CF for almost ten years. I was anchor of the release integration team that conceived of and developed cf-deployment, guided the design of the v6 CLI, orchestrated the transition of Pivotal Web Services from cf-release to multi-deployment/cell-block cf-deployment, and have recently resigned from VMware after years of being a Technology Lead focused on release, packaging, and upgrade related issues for TAS, VMware's commercialized distribution. 13 | 14 | I care deeply about Cloud Foundry and related technologies like Concourse, and bring significant experience and expertise in transitions and roadmaps through eras of technological and organizational change. 15 | -------------------------------------------------------------------------------- /elections/2023/TOC/candidate-stephanme.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Stephan Merker 3 | 4 | ID: stephanme 5 | 6 | info: 7 | - employer: SAP SE 8 | - slack: stephanme 9 | - github: stephanme 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: Being the product owner of one of the teams responsible for operating some of the biggest Cloud Foundry deployments world-wide, I have been active in the Cloud Foundry community for the past 8+ years. 13 | I am a current member of the Cloud Foundry Technical Oversight Committee and I contribute to the Application Runtime Deployments and Application Runtime Interfaces working groups. If re-elected I would continue to improve the cloudfoundry Github org automation which facilitates the project setup and onboarding of new community members. 14 | -------------------------------------------------------------------------------- /elections/2023/TOC/election.yaml: -------------------------------------------------------------------------------- 1 | name: 2023 CFF Technical Oversight Committee election 2 | organization: Cloud Foundry Foundation 3 | start_datetime: 2023-06-02 06:59:00 # 11:59 pm PDT, 01 Jun 2023 4 | end_datetime: 2023-06-17 06:59:00 # 11:59 pm PDT, 16 Jun 2023 5 | no_winners: 3 6 | allow_no_opinion: True 7 | delete_after: True 8 | show_candidate_fields: 9 | - employer 10 | - github 11 | - slack 12 | election_officers: 13 | - christopherclark 14 | - ramiyengar 15 | - sgreenberg 16 | - AP-Hunt 17 | - beyhan 18 | - emalm 19 | - rkoster 20 | - stephanme 21 | eligibility: Members of the Cloud Foundry organization with 25 or more contributions in the last year may vote. See [the voter eligibility section](https://github.com/cloudfoundry/community/blob/main/toc/TOC.md#community-eligibility-to-vote-in-toc-elections) for more information. 22 | exception_description: If you feel you are eligible to vote but are not represented in the list of voters, please request an exception to allow you to vote via the Elekto application. 23 | exception_due: 2023-06-14 06:59:00 # 11:59 pm PT, 13 Jun 2023 24 | -------------------------------------------------------------------------------- /elections/2023/TOC/election_desc.md: -------------------------------------------------------------------------------- 1 | The role of this election is to fill the three (3) seats due for election this year on the Cloud Foundry Foundation TOC. The elected members will serve two (2) year terms. This is a brief summary of the election; for more details, such as how to become a candidate, [see the README](https://github.com/cloudfoundry/community/tree/main/elections/2023/TOC#readme). 2 | 3 | ## Eligibility 4 | 5 | All contributors with 25 or more contributions to any Cloud Foundry Foundation project over the last year are eligible to vote. You will see either ELIGIBLE or NOT ELIGIBLE at the top of this screen. If Elekto fails to recognize you as eligible to vote in this election even though you believe you should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2023---TOC/exception) or via an issue on the community repository. The deadline for filing exceptions is June 13th, 11:59 pm PT. 6 | 7 | ## Schedule 8 | 9 | May 18: Election is announced and candidate nomination period begins 10 | June 1, 5:00 pm PDT: Candidate nomination period ends 11 | June 1, 11:59 pm PDT: Election begins 12 | June 16, 11:59 pm PDT: Election ends 13 | June 20: Announcement of results 14 | 15 | ## Changing Your Vote 16 | 17 | With Elekto, you may revoke and re-cast your ballot until the election deadline of June 16th. To do so, set a passphrase when you cast your ballot; as long as you have that passphrase, you may re-cast your ballot by returning to the site. 18 | -------------------------------------------------------------------------------- /elections/2023/TOC/results.md: -------------------------------------------------------------------------------- 1 | # 2023 CFF Technical Oversight Committee Election Results 2 | 3 | Many thanks to all the nominees and everyone who voted in the election! 4 | 5 | I’m pleased to announce our new TOC members will be: 6 | 7 | * Amelia Downs (VMware) 8 | * Stephan Merker (SAP) - reelected 9 | * Chris McGowan (Cloud.gov) 10 | 11 | They'll be joining Ruben Koster (VMware) and Beyhan Veli (SAP), whose seats will be up for election next year. 12 | 13 | Congratulations to Amelia, Stephan and Chris! 14 | 15 | ## Details 16 | 17 | Actual votes cast: 67 18 | 19 | Complete results of the election, using the Schulze rules for Condorcet completion, are: 20 | 21 | * Amelia Downs 22 | * Stephan Merker 23 | * Chris McGowan 24 | * Jesse Alford 25 | 26 | Records of all cast ballots are available in [CSV format here](https://github.com/cloudfoundry/community/blob/main/elections/2023/TOC/ballots.csv). 27 | -------------------------------------------------------------------------------- /elections/2024/Paketo-SC/README.md: -------------------------------------------------------------------------------- 1 | # 2024 Paketo Buildpacks Steering Committee Election Guide 2 | 3 | 4 | ## Overview 5 | 6 | The role of this inuagural election is to fill one (1) seat on the Paketo Buildpacks Steering Committee. The nominee who receive the most votes will serve a two (2) year term. 7 | 8 | For more information on the Paketo Buildpack Steering Committee, [please read this](https://github.com/paketo-buildpacks/community/blob/main/STEERING.md). 9 | 10 | 11 | ## Schedule 12 | 13 | - **May 22**: Election is announced and candidate nomination period begins 14 | - **June 7, 5:00 pm PDT**: Candidate nomination period ends 15 | - **June 7, 11:59 pm PDT**: Election begins 16 | - **June 18, 11:59 pm PDT**: Election ends 17 | - **June 20**: Announcement of results 18 | 19 | 20 | ## Candidate Processes 21 | 22 | 23 | ### Nominations 24 | 25 | 26 | Every eligible voter can nominate candidates for the Steering Committee, and we encourage you to do so. If you are 27 | eligible to serve on the committee, you can self-nominate. If you want to nominate someone else, do so as 28 | well. 29 | 30 | 31 | You can nominate someone for the Steering Committee by [submitting an issue using this template](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=paketo-buildpacks-sc-candidate-nomination.md&title=Paketo+Buildpacks+Steering+Committee+Candidate+Nomination+for+%5BPerson+Name%5D). 32 | 33 | 34 | The deadline is June 3rd to be nominated (and for the nominee to indicate acceptance). 35 | 36 | 37 | It is strongly recommended that you confirm that a nominee is interested and willing 38 | to accept the nomination prior to submitting the nomination issue. 39 | 40 | 41 | ### Confirming Nominee Eligibility 42 | 43 | 44 | Once a nomination is received, the CFF staff or existing Steering Committee will contact the nominee to confirm acceptance 45 | of the nomination. If the nominee accepts, they will be added to the list of nominees at the bottom 46 | of this file. The nomination issue will be closed, noting if the nominee accepted or declined the 47 | nomination. 48 | 49 | 50 | ## Voting Process 51 | 52 | 53 | The 2024 Paketo Buildpacks Steering Committee election will be conducted using a [CFF-managed instance](https://elections.cloudfoundry.org) of [Elekto](https://elekto.dev), a CNCF infrastructure project 54 | that implements Condorcet ranked-choice voting using the Schulze method. Elekto relies on GitHub 55 | for user identity and authentication, which better matches how members interact with the Cloud 56 | Foundry community on a day-to-day basis than the email identity that the [Condorcet Internet Voting 57 | Service](https://civs1.civs.us/) requires. 58 | 59 | As stated in the Paketo [Steering Committee documentation](https://github.com/paketo-buildpacks/community/blob/main/STEERING.md), any individual who has contributed to Paketo Buildpacks in the twelve months prior to the election is eligible to vote in the Steering Committee election. Contributions include, but are not limited to, opening PRs, reviewing and commenting on PRs, opening and commenting on issues, writing design docs, commenting on design docs, participating in mailing list discussions and participating in working groups. 60 | 61 | If Elekto fails to recognize you as eligible to vote in this election even though you believe you 62 | should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2024---Paketo-SC/exception) or [via an issue on the 63 | community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-paketo-buildpacks-sc-election.md&title=Request+to+be+an+elector+for+Paketo+Steering+Committee+election). 64 | 65 | Once the official election period starts, you will be able to rank the candidates in your preferred 66 | order and submit your ballot. You may set a password on your ballot, which is required to change 67 | your ballot later within the election period. Once the election period ends, all ballots are final. 68 | 69 | All ballot data for Elekto is stored on a database managed by the CFF staff, and is not shared with 70 | third parties. Individual ballot data is encrypted, and ballot data can be retrieved only in 71 | aggregate form. 72 | 73 | 74 | ## Election Results 75 | 76 | 77 | The newly elected body will be announced via cf-dev@lists.cloudfoundry.org and main@lists.paketo.io on 20 Jun, 2024. 78 | 79 | 80 | Following the announcement, the voting results and winners will be published. 81 | -------------------------------------------------------------------------------- /elections/2024/Paketo-SC/ballots.csv: -------------------------------------------------------------------------------- 1 | loewenstein-sap,jericop 2 | 2,1 3 | 1,2 4 | 1,2 5 | 2,1 6 | 1,2 7 | 1,2 8 | 2,1 9 | 1,No opinion 10 | 1,2 11 | 2,1 12 | -------------------------------------------------------------------------------- /elections/2024/Paketo-SC/candidate-jericop.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Jerico Pena 3 | 4 | ID: jericop 5 | 6 | info: 7 | - employer: Rapid7 8 | - slack: Jerico Pena 9 | - github: jericop 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: I have been an active member of the paketo and cloud native buildpacks community for the last 2 years. Since my involvement I have contributed to pushing forward multi-arch support both within paketo and upstream in the CNB project. I believe I bring a valuable outside perspective not only as an end-user but also as a buildpack author and operator. 13 | -------------------------------------------------------------------------------- /elections/2024/Paketo-SC/candidate-loewenstein-sap.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Jan von Löwenstein 3 | 4 | ID: loewenstein-sap 5 | 6 | info: 7 | - employer: SAP SE 8 | - slack: loewenstein 9 | - github: loewenstein-sap 10 | ------------------------------------------------------------- 11 | 12 | Nomination Statement: I have been active in the Cloud Foundry community (as Bosh maintainer and later founding TOC member) since 2015. I am currently a member of the Paketo Steering Committee. My team has been looking into Paketo buildpacks since around 2019 and we are regular contributors to the project. 13 | Managing the backlog of my team, I speak a lot with buildpack users. At the same time I believe I still hold enough technical grasp to be able to translate between requirements and technical project direction. 14 | -------------------------------------------------------------------------------- /elections/2024/Paketo-SC/election.yaml: -------------------------------------------------------------------------------- 1 | name: 2024 Paketo Buildpacks Steering Committee election 2 | organization: Cloud Foundry Foundation 3 | start_datetime: 2024-06-08 06:59:00 # 11:59 pm PDT, 07 Jun 2024 4 | end_datetime: 2024-06-19 06:59:00 # 11:59 pm PDT, 18 Jun 2024 5 | no_winners: 1 6 | allow_no_opinion: True 7 | delete_after: True 8 | show_candidate_fields: 9 | - employer 10 | - github 11 | - slack 12 | election_officers: 13 | - christopherclark 14 | - emalm 15 | - dmikusa 16 | - sgreenberg 17 | eligibility: Any individual who has contributed to Paketo Buildpacks in the twelve months prior to the election is eligible to vote in the Steering Committee election. Each election cycle, an initial set of voters will be identified through automated reporting. Any individual who has at least 10 measurable contributions in the last 12 months will be automatically added to the eligible voter list. 18 | exception_description: If you feel you are eligible to vote but are not represented in the list of voters, please request an exception to allow you to vote via the Elekto application. 19 | exception_due: 2024-06-17 06:59:00 # 11:59 pm PT, 17 Jun 2024 20 | -------------------------------------------------------------------------------- /elections/2024/Paketo-SC/election_desc.md: -------------------------------------------------------------------------------- 1 | The role of this election is to fill the one (1) seat due for election this year on the Paketo Buildpacks Steering Committee. The nominee who recieves the most votes will serve a two (2) year term. This is a brief summary of the election; for more details, such as how to become a candidate, [see the README](https://github.com/cloudfoundry/community/tree/main/elections/2024/Paketo#readme). 2 | 3 | ## Eligibility 4 | 5 | Any individual who has contributed to Paketo Buildpacks in the twelve months prior to the election is eligible to vote in the Steering Committee election. You will see either ELIGIBLE or NOT ELIGIBLE at the top of this screen. If Elekto fails to recognize you as eligible to vote in this election even though you believe you should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2024---Paketo-SC/exception) or [via an issue on the community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-paketo-buildpacks-sc-election.md&title=Request+to+be+an+elector+for+Paketo+Steering+Committee+election). The deadline for filing exceptions is June 16th, 11:59 pm PT. 6 | 7 | ## Schedule 8 | 9 | May 22: Election is announced and candidate nomination period begins 10 | June 7, 5:00 pm PDT: Candidate nomination period ends 11 | June 7, 11:59 pm PDT: Election begins 12 | June 18, 11:59 pm PDT: Election ends 13 | June 20: Announcement of results 14 | 15 | ## Changing Your Vote 16 | 17 | With Elekto, you may revoke and re-cast your ballot until the election deadline of June 18th. To do so, set a passphrase when you cast your ballot; as long as you have that passphrase, you may re-cast your ballot by returning to the site. 18 | -------------------------------------------------------------------------------- /elections/2024/Paketo-SC/results.md: -------------------------------------------------------------------------------- 1 | # 2024 Paketo Steering Committee Election Results 2 | 3 | Many thanks to the nominees and everyone who voted in the election. 4 | 5 | Congratulations to Jan von Löwenstein who been re-elected to the Paketo Steering Committee for a two year term! 6 | 7 | ## Details 8 | 9 | Actual votes cast: 10 10 | 11 | Complete results of the election, using the Schulze rules for Condorcet completion, are: 12 | 13 | * Jan von Löwenstein 14 | * Jerico Pena 15 | 16 | Records of all cast ballots are available in [CSV format here](https://github.com/cloudfoundry/community/blob/main/elections/2024/Paketo-SC/ballots.csv). 17 | -------------------------------------------------------------------------------- /elections/2024/Paketo-SC/voters.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | eligible_voters: 3 | - AidanDelaney 4 | - ajdergute 5 | - antechrestos 6 | - anthonydahanne 7 | - antoinerg 8 | - arjun024 9 | - AshwinSridharan0410 10 | - badri 11 | - BarDweller 12 | - benjie91 13 | - bitgully 14 | - braunsonm 15 | - brayanhenao 16 | - c0d1ngm0nk3y 17 | - candrews 18 | - chuckquinnIV 19 | - conzetti 20 | - dashaun 21 | - dilipgb 22 | - divoxx 23 | - dmikusa 24 | - dmitry-mightydevops 25 | - durcon 26 | - fniephaus 27 | - ForestEckhardt 28 | - gajicdev 29 | - getouo 30 | - hashlash 31 | - hirosat 32 | - Infra-Red 33 | - jellehelsen 34 | - jericop 35 | - joeyweisband 36 | - joshuatcasey 37 | - jpastoor 38 | - kafkaproserverless 39 | - kevin-ortega 40 | - kworkbee 41 | - lmarchione-r7 42 | - loewenstein 43 | - mamachanko 44 | - matejvasek 45 | - mecseid 46 | - mhdawson 47 | - mhdawson 48 | - mhoshi-vm 49 | - modulo11 50 | - nlsrchtr 51 | - ofirm93 52 | - olibutzki 53 | - pacostas 54 | - patbaumgartner 55 | - pax95 56 | - pbusko 57 | - PerfectSlayer 58 | - phil9909 59 | - pivotal-david-osullivan 60 | - radoshi 61 | - robdimsdale 62 | - ryanmoran 63 | - sap-ali 64 | - saugion 65 | - scottfrederick 66 | - sdeleuze 67 | - semmet95 68 | - sgaist 69 | - showpune 70 | - sophiewigmore 71 | - sylvainkalache 72 | - tarzzz 73 | - thitch97 74 | - thomasvitale 75 | - tinedel 76 | - tisvictress 77 | - vuhp 78 | - vvlevchenko 79 | - weirong-zhu 80 | - wpater 81 | - ywk253100 82 | - zhoufenqin 83 | - zoidbergwill 84 | -------------------------------------------------------------------------------- /elections/2024/TOC/README.md: -------------------------------------------------------------------------------- 1 | # 2024 CFF TOC Election Guide 2 | 3 | 4 | ## Overview 5 | 6 | 7 | Each year, the CFF technical community holds an election for open seats on the 8 | Technical Oversight Committee (TOC). The rules governing this election are set in the 9 | [CFF's project charter](../../../governing-board/charter.md) (See section 7(b) and 7(e) 10 | for the relevant details). 11 | 12 | 13 | ## Schedule 14 | 15 | - **May 22**: Election is announced and candidate nomination period begins 16 | - **June 7, 5:00 pm PDT**: Candidate nomination period ends 17 | - **June 7, 11:59 pm PDT**: Election begins 18 | - **June 18, 11:59 pm PDT**: Election ends 19 | - **June 20**: Announcement of results 20 | 21 | 22 | ## Candidate Processes 23 | 24 | 25 | ### Nominations 26 | 27 | 28 | Every eligible voter can nominate candidates for the TOC, and we encourage you to do so. If you are 29 | eligible to serve on the TOC, you can self nominate! If you want to nominate someone else, do so as 30 | well! 31 | 32 | 33 | You can nominate someone for the TOC by [submitting an issue using this template](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=toc-candidate-nomination.md&title=TOC+Candidate+Nomination+for+%5BPerson+Name%5D). 34 | 35 | 36 | The deadline is June 3nd to be nominated (and for the nominee to indicate acceptance). 37 | 38 | 39 | It is strongly recommended that you confirm that a nominee is interested and willing 40 | to accept the nomination prior to submitting the nomination issue. 41 | 42 | 43 | ### Confirming Nominee Eligibility 44 | 45 | 46 | Once a nomination is received, the CFF staff will contact the nominee to confirm acceptance 47 | of the nomination. If the nominee accepts, they will be added to the list of nominees at the bottom 48 | of this file. The nomination issue will be closed, noting if the nominee accepted or declined the 49 | nomination. 50 | 51 | 52 | ## Voting Process 53 | 54 | 55 | The 2024 TOC election will be conducted using a [CFF-managed instance](https://elections.cloudfoundry.org) of [Elekto](https://elekto.dev), a CNCF infrastructure project 56 | that implements Condorcet ranked-choice voting using the Schulze method. Elekto relies on GitHub 57 | for user identity and authentication, which better matches how members interact with the Cloud 58 | Foundry community on a day-to-day basis than the email identity that the [Condorcet Internet Voting 59 | Service](https://civs1.civs.us/) requires. 60 | 61 | Any individual who has contributed to CFF projects or technical working groups in the twelve months prior to the election is eligible to vote in the TOC election. Contributions include, but are not limited to, opening PRs, reviewing and commenting on PRs, opening and commenting on issues, writing design docs, commenting on design docs, participating in mailing list discussions and participating in working groups. 62 | 63 | If Elekto fails to recognize you as eligible to vote in this election even though you believe you 64 | should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2024---TOC/exception) or [via an issue on the 65 | community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-toc-election.md&title=Request+to+be+an+elector+for+TOC+election). 66 | 67 | Once the official election period starts, you will be able to rank the candidates in your preferred 68 | order and submit your ballot. You may set a password on your ballot, which is required to change 69 | your ballot later within the election period. Once the election period ends, all ballots are final. 70 | 71 | All ballot data for Elekto is stored on a database managed by the CFF staff, and is not shared with 72 | third parties. Individual ballot data is encrypted, and ballot data can be retrieved only in 73 | aggregate form. 74 | 75 | 76 | ## Election Results 77 | 78 | 79 | The newly elected body will be announced via cf-dev@lists.cloudfoundry.org on 20 Jun, 2024. 80 | 81 | 82 | Following the announcement, the voting results and winners will be published. 83 | -------------------------------------------------------------------------------- /elections/2024/TOC/candidate-beyhan.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Beyhan Veli 3 | ID: beyhan 4 | info: 5 | - employer: SAP SE 6 | - slack: beyhan 7 | - github: beyhan 8 | ------------------------------------------------------------- 9 | 10 | Nomination Statement: I have been active in the Cloud Foundry community for the past 9+ years supporting the Foundational Infrastructure WG, as TOC member and as CF user who brings new requirements to the CF platform derived from SAP use cases. If re-elected I would like to continue contributing to the CF platform evolution and support the CFF community. 11 | -------------------------------------------------------------------------------- /elections/2024/TOC/candidate-rkoster.md: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------- 2 | name: Ruben Koster 3 | ID: rkoster 4 | info: 5 | - employer: VMware Tanzu by Broadcom 6 | - slack: rkoster 7 | - github: rkoster 8 | ------------------------------------------------------------- 9 | 10 | Nomination Statement: I have been active in the Cloud Foundry community for the past 11+ years supporting the Foundational Infrastructure WG, as TOC member and as CF user who brings new requirements to the CF platform derived from Broadcom use cases. If re-elected I would like to continue contributing to the CF platform evolution and support the CFF community. 11 | -------------------------------------------------------------------------------- /elections/2024/TOC/election.yaml: -------------------------------------------------------------------------------- 1 | name: 2024 CFF Technical Oversight Committee election 2 | organization: Cloud Foundry Foundation 3 | start_datetime: 2024-06-08 06:59:00 # 11:59 pm PDT, 07 Jun 2024 4 | end_datetime: 2024-06-19 06:59:00 # 11:59 pm PDT, 18 Jun 2024 5 | no_winners: 2 6 | allow_no_opinion: True 7 | delete_after: True 8 | show_candidate_fields: 9 | - employer 10 | - github 11 | - slack 12 | election_officers: 13 | - ameowlia 14 | - chrismcgowan 15 | - christopherclark 16 | - emalm 17 | - ramiyengar 18 | - sgreenberg 19 | - stephanme 20 | eligibility: Any individual who has contributed to any Cloud Foundry Foundation project in the twelve months prior to the election is eligible to vote in the TOC election. See [the voter eligibility section](https://github.com/cloudfoundry/community/blob/main/toc/TOC.md#community-eligibility-to-vote-in-toc-elections) for more information. 21 | exception_description: If you feel you are eligible to vote but are not represented in the list of voters, please request an exception to allow you to vote via the Elekto application. 22 | exception_due: 2024-06-17 06:59:00 # 11:59 pm PT, 17 Jun 2024 23 | -------------------------------------------------------------------------------- /elections/2024/TOC/election_desc.md: -------------------------------------------------------------------------------- 1 | The role of this election is to fill the two (2) seats due for election this year on the Cloud Foundry Foundation TOC. The elected members will serve two (2) year terms. This is a brief summary of the election; for more details, such as how to become a candidate, [see the README](https://github.com/cloudfoundry/community/tree/main/elections/2024/TOC#readme). 2 | 3 | ## Eligibility 4 | 5 | Anyone who has contributed to a Cloud Foundry Foundation project over the last year is eligible to vote. You will see either ELIGIBLE or NOT ELIGIBLE at the top of this screen. If Elekto fails to recognize you as eligible to vote in this election even though you believe you should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2024---TOC/exception) or via an issue on the community repository. The deadline for filing exceptions is June 16th, 11:59 pm PT. 6 | 7 | ## Schedule 8 | 9 | May 22: Election is announced and candidate nomination period begins 10 | June 7, 5:00 pm PDT: Candidate nomination period ends 11 | June 7, 11:59 pm PDT: Election begins 12 | June 18, 11:59 pm PDT: Election ends 13 | June 20: Announcement of results 14 | 15 | ## Changing Your Vote 16 | 17 | With Elekto, you may revoke and re-cast your ballot until the election deadline of June 18th. To do so, set a passphrase when you cast your ballot; as long as you have that passphrase, you may re-cast your ballot by returning to the site. 18 | -------------------------------------------------------------------------------- /elections/2024/TOC/results.md: -------------------------------------------------------------------------------- 1 | # 2024 CFF Technical Oversight Committee Election Results 2 | 3 | Congratulations to Ruben Koster (VMware) and Beyhan Veli (SAP), who have each been re-elected to two year terms to the Technical Oversight Committee! 4 | 5 | ## Details 6 | 7 | As Ruben and Beyhan were the only candidates running for these two spots, there were no ballot results to upload this cycle. 8 | -------------------------------------------------------------------------------- /elections/2024/TOC/voters.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | eligible_voters: 3 | - a-b 4 | - a-hassanin 5 | - a18e 6 | - abg 7 | - acosta11 8 | - acrmp 9 | - adrianhoelzl-sap 10 | - AidanDelaney 11 | - ajdergute 12 | - alperdedeoglu 13 | - ameowlia 14 | - anita-flegg 15 | - anoopjb 16 | - anshrupani 17 | - antechrestos 18 | - anthonydahanne 19 | - antoinerg 20 | - AP-Hunt 21 | - aramprice 22 | - arjun024 23 | - asalan316 24 | - b1tamara 25 | - BarDweller 26 | - Benjamintf1 27 | - beyhan 28 | - bgandon 29 | - Birdrock 30 | - bitgully 31 | - blgm 32 | - blora1 33 | - bonzofenix 34 | - boyan-velinov 35 | - braunsonm 36 | - brayanhenao 37 | - bruce-ricard 38 | - c0d1ngm0nk3y 39 | - candrews 40 | - ccjaimes 41 | - chombium 42 | - ChrisMcGowan 43 | - christopherclark 44 | - ChuckQuinnIV 45 | - clintyoshimura 46 | - crhntr 47 | - ctlong 48 | - cunnie 49 | - D023954 50 | - dalvarado 51 | - danail-branekov 52 | - davewalter 53 | - dimivel 54 | - dlresende 55 | - dmikusa 56 | - domdom82 57 | - dsabeti 58 | - dsboulder 59 | - duanemay 60 | - eaglerainbow 61 | - ebroberson 62 | - ElsaChelala 63 | - emalm 64 | - EugeneTitarchuk 65 | - evanfarrar 66 | - favna 67 | - Felix Moehler 68 | - fifthposition 69 | - FloThinksPi 70 | - fmoehler 71 | - fnaranjo-vmw 72 | - fniephaus 73 | - ForestEckhardt 74 | - gberche-orange 75 | - gcapizzi 76 | - geigerj0 77 | - geofffranks 78 | - georgethebeatle 79 | - Gerg 80 | - gflex 81 | - gmllt 82 | - gururajsh 83 | - HenryBorys 84 | - hmanukyanVMw 85 | - hsinn0 86 | - iaftab-alam 87 | - ifindlay-cci 88 | - ikasarov 89 | - IvanBorislavovDimitrov 90 | - jaristiz 91 | - jbooherl 92 | - jericop 93 | - jhvhs 94 | - jintusebastian 95 | - jochenehret 96 | - joergdw 97 | - johha 98 | - joshuatcasey 99 | - jpalermo 100 | - jrussett 101 | - julian-hj 102 | - JVecsei1 103 | - KafkaProServerless 104 | - kathap 105 | - kevin-ortega 106 | - kieron-dev 107 | - kimago 108 | - kinjelom 109 | - klakin-pivotal 110 | - klapkov 111 | - klaus-sap 112 | - kmarkwardt-vmware 113 | - liornabat-sealights 114 | - lmarchione-r7 115 | - lnguyen 116 | - loewenstein 117 | - Malsourie 118 | - mamachanko 119 | - manavsaraf1 120 | - MarcPaquette 121 | - mariash 122 | - marsteg 123 | - matejvasek 124 | - matt-royal 125 | - maxmoehl 126 | - MerricdeLauney 127 | - metron2 128 | - mhdawson 129 | - mikeroda 130 | - mkocher 131 | - modulo11 132 | - mogul 133 | - moleske 134 | - Mrizwanshaik 135 | - mvach 136 | - nicklas-dohrn 137 | - nouseforaname 138 | - OliverMautschke 139 | - pacostas 140 | - pacphi 141 | - paulcwarren 142 | - pbusko 143 | - peanball 144 | - peterhaochen47 145 | - phil9909 146 | - philippthun 147 | - pivotal-david-osullivan 148 | - pivotal-marcela-campo 149 | - pivotalgeorge 150 | - PlamenDoychev 151 | - plowin 152 | - radito3 153 | - radoslav-tomov 154 | - ragaskar 155 | - ramonskie 156 | - reedr3 157 | - reneighbor 158 | - rkoster 159 | - robdimsdale 160 | - Rohit04061992 161 | - rroberts2222 162 | - rthill91 163 | - ryanmoran 164 | - s-yonkov-yonkov 165 | - salzmannsusan 166 | - scottfrederick 167 | - selzoc 168 | - semmet95 169 | - sethboyles 170 | - sgaist 171 | - shanman190 172 | - showpune 173 | - silvestre 174 | - sleungcy 175 | - sneal 176 | - sophiewigmore 177 | - spgreenberg 178 | - ssunka 179 | - stephanme 180 | - strehle 181 | - svcboteos 182 | - svkrieger 183 | - swalchemist 184 | - tack-sap 185 | - Tallicia 186 | - tcdowney 187 | - ten4o 188 | - theghost5800 189 | - thitch97 190 | - ThomasVitale 191 | - tilieva 192 | - TisVictress 193 | - torsten-sap 194 | - totherme 195 | - tpbrisco 196 | - tylerbenson 197 | - vinaybheri 198 | - vipinvkmenon 199 | - vkalapov 200 | - vlast3k 201 | - VRBogdanov 202 | - WeiQuan0605 203 | - weirong-zhu 204 | - winkingturtle-vmw 205 | - xiaozhu36 206 | - yangdeyue-root 207 | - Yavor16 208 | - ystros 209 | - ZPascal 210 | -------------------------------------------------------------------------------- /elections/2025/Paketo-SC/README.md: -------------------------------------------------------------------------------- 1 | # 2025 Paketo Buildpacks Steering Committee Election Guide 2 | 3 | 4 | ## Overview 5 | 6 | The role of this inuagural election is to fill two (2) seats on the Paketo Buildpacks Steering Committee. The nominees who receive the most votes will serve two (2) year terms. 7 | 8 | For more information on the Paketo Buildpack Steering Committee, [please read this](https://github.com/paketo-buildpacks/community/blob/main/STEERING.md). 9 | 10 | 11 | ## Schedule 12 | 13 | - **June 2**: Election is announced and candidate nomination period begins 14 | - **June 12, 5:00 pm PDT**: Candidate nomination period ends 15 | - **June 12, 11:59 pm PDT**: Election begins 16 | - **June 24, 11:59 pm PDT**: Election ends 17 | - **June 26**: Announcement of results 18 | 19 | 20 | ## Candidate Processes 21 | 22 | 23 | ### Nominations 24 | 25 | 26 | Every eligible voter can nominate candidates for the Steering Committee, and we encourage you to do so. If you are 27 | eligible to serve on the committee, you can self-nominate. If you want to nominate someone else, do so as 28 | well. 29 | 30 | 31 | You can nominate someone for the Steering Committee by [submitting an issue using this template](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=paketo-buildpacks-sc-candidate-nomination.md&title=Paketo+Buildpacks+Steering+Committee+Candidate+Nomination+for+%5BPerson+Name%5D). 32 | 33 | 34 | The deadline is June 12th to be nominated (and for the nominee to indicate acceptance). 35 | 36 | 37 | It is strongly recommended that you confirm that a nominee is interested and willing 38 | to accept the nomination prior to submitting the nomination issue. 39 | 40 | 41 | ### Confirming Nominee Eligibility 42 | 43 | 44 | Once a nomination is received, the CFF staff or existing Steering Committee will contact the nominee to confirm acceptance 45 | of the nomination. If the nominee accepts, they will be added to the list of nominees at the bottom 46 | of this file. The nomination issue will be closed, noting if the nominee accepted or declined the 47 | nomination. 48 | 49 | 50 | ## Voting Process 51 | 52 | 53 | The 2025 Paketo Buildpacks Steering Committee election will be conducted using a [CFF-managed instance](https://elections.cloudfoundry.org) of [Elekto](https://elekto.dev), a CNCF infrastructure project 54 | that implements Condorcet ranked-choice voting using the Schulze method. Elekto relies on GitHub 55 | for user identity and authentication, which better matches how members interact with the Cloud 56 | Foundry community on a day-to-day basis than the email identity that the [Condorcet Internet Voting 57 | Service](https://civs1.civs.us/) requires. 58 | 59 | As stated in the Paketo [Steering Committee documentation](https://github.com/paketo-buildpacks/community/blob/main/STEERING.md), any individual who has contributed to Paketo Buildpacks in the twelve months prior to the election is eligible to vote in the Steering Committee election. Contributions include, but are not limited to, opening PRs, reviewing and commenting on PRs, opening and commenting on issues, writing design docs, commenting on design docs, participating in mailing list discussions and participating in working groups. 60 | 61 | If Elekto fails to recognize you as eligible to vote in this election even though you believe you 62 | should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2025---Paketo-SC/exception) or [via an issue on the 63 | community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-paketo-buildpacks-sc-election.md&title=Request+to+be+an+elector+for+Paketo+Steering+Committee+election). 64 | 65 | Once the official election period starts, you will be able to rank the candidates in your preferred 66 | order and submit your ballot. You may set a password on your ballot, which is required to change 67 | your ballot later within the election period. Once the election period ends, all ballots are final. 68 | 69 | All ballot data for Elekto is stored on a database managed by the CFF staff, and is not shared with 70 | third parties. Individual ballot data is encrypted, and ballot data can be retrieved only in 71 | aggregate form. 72 | 73 | 74 | ## Election Results 75 | 76 | 77 | The newly elected body will be announced via cf-dev@lists.cloudfoundry.org and main@lists.paketo.io on 26 Jun, 2025. 78 | 79 | 80 | Following the announcement, the voting results and winners will be published. 81 | -------------------------------------------------------------------------------- /elections/2025/Paketo-SC/election.yaml: -------------------------------------------------------------------------------- 1 | name: 2025 Paketo Buildpacks Steering Committee election 2 | organization: Cloud Foundry Foundation 3 | start_datetime: 2025-06-12 06:59:00 # 11:59 pm PDT, 12 Jun 2025 4 | end_datetime: 2025-06-24 06:59:00 # 11:59 pm PDT, 24 Jun 2025 5 | no_winners: 1 6 | allow_no_opinion: True 7 | delete_after: True 8 | show_candidate_fields: 9 | - employer 10 | - github 11 | - slack 12 | election_officers: 13 | - loewenstein-sap 14 | - christopherclark 15 | - sgreenberg 16 | eligibility: Any individual who has contributed to Paketo Buildpacks in the twelve months prior to the election is eligible to vote in the Steering Committee election. Each election cycle, an initial set of voters will be identified through automated reporting. Any individual who has at least 10 measurable contributions in the last 12 months will be automatically added to the eligible voter list. 17 | exception_description: If you feel you are eligible to vote but are not represented in the list of voters, please request an exception to allow you to vote via the Elekto application. 18 | exception_due: 2025-06-22 06:59:00 # 11:59 pm PT, 22 Jun 2025 19 | -------------------------------------------------------------------------------- /elections/2025/Paketo-SC/election_desc.md: -------------------------------------------------------------------------------- 1 | The role of this election is to fill the two (2) seats due for election this year on the Paketo Buildpacks Steering Committee. The nominees who recieves the most votes will serve two (2) year terms. This is a brief summary of the election; for more details, such as how to become a candidate, [see the README](https://github.com/cloudfoundry/community/tree/main/elections/2025/Paketo-SC#readme). 2 | 3 | ## Eligibility 4 | 5 | Any individual who has contributed to Paketo Buildpacks in the twelve months prior to the election is eligible to vote in the Steering Committee election. You will see either ELIGIBLE or NOT ELIGIBLE at the top of this screen. If Elekto fails to recognize you as eligible to vote in this election even though you believe you should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2025---Paketo-SC/exception) or [via an issue on the community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-paketo-buildpacks-sc-election.md&title=Request+to+be+an+elector+for+Paketo+Steering+Committee+election). The deadline for filing exceptions is June 22nd, 11:59 pm PT. 6 | 7 | ## Schedule 8 | 9 | June 2: Election is announced and candidate nomination period begins 10 | June 12, 5:00 pm PDT: Candidate nomination period ends 11 | June 12, 11:59 pm PDT: Election begins 12 | June 24, 11:59 pm PDT: Election ends 13 | June 26: Announcement of results 14 | 15 | ## Changing Your Vote 16 | 17 | With Elekto, you may revoke and re-cast your ballot until the election deadline of June 24th. To do so, set a passphrase when you cast your ballot; as long as you have that passphrase, you may re-cast your ballot by returning to the site. 18 | -------------------------------------------------------------------------------- /elections/2025/TOC/README.md: -------------------------------------------------------------------------------- 1 | # 2025 CFF TOC Election Guide 2 | 3 | 4 | ## Overview 5 | 6 | 7 | Each year, the CFF technical community holds an election for open seats on the 8 | Technical Oversight Committee (TOC). The rules governing this election are set in the 9 | [CFF's project charter](../../../governing-board/charter.md) (See section 7(b) and 7(e) 10 | for the relevant details). 11 | 12 | 13 | ## Schedule 14 | 15 | - **June 2**: Election is announced and candidate nomination period begins 16 | - **June 12, 5:00 pm PDT**: Candidate nomination period ends 17 | - **June 12, 11:59 pm PDT**: Election begins 18 | - **June 24, 11:59 pm PDT**: Election ends 19 | - **June 26**: Announcement of results 20 | 21 | 22 | ## Candidate Processes 23 | 24 | 25 | ### Nominations 26 | 27 | 28 | Every eligible voter can nominate candidates for the TOC, and we encourage you to do so. If you are 29 | eligible to serve on the TOC, you can self nominate! If you want to nominate someone else, do so as 30 | well! 31 | 32 | 33 | You can nominate someone for the TOC by [submitting an issue using this template](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=toc-candidate-nomination.md&title=TOC+Candidate+Nomination+for+%5BPerson+Name%5D). 34 | 35 | 36 | The deadline is June 12th to be nominated (and for the nominee to indicate acceptance). 37 | 38 | 39 | It is strongly recommended that you confirm that a nominee is interested and willing 40 | to accept the nomination prior to submitting the nomination issue. 41 | 42 | 43 | ### Confirming Nominee Eligibility 44 | 45 | 46 | Once a nomination is received, the CFF staff will contact the nominee to confirm acceptance 47 | of the nomination. If the nominee accepts, they will be added to the list of nominees at the bottom 48 | of this file. The nomination issue will be closed, noting if the nominee accepted or declined the 49 | nomination. 50 | 51 | 52 | ## Voting Process 53 | 54 | 55 | The 2025 TOC election will be conducted using a [CFF-managed instance](https://elections.cloudfoundry.org) of [Elekto](https://elekto.dev), a CNCF infrastructure project 56 | that implements Condorcet ranked-choice voting using the Schulze method. Elekto relies on GitHub 57 | for user identity and authentication, which better matches how members interact with the Cloud 58 | Foundry community on a day-to-day basis than the email identity that the [Condorcet Internet Voting 59 | Service](https://civs1.civs.us/) requires. 60 | 61 | Any individual who has contributed to CFF projects or technical working groups in the twelve months prior to the election is eligible to vote in the TOC election. Contributions include, but are not limited to, opening PRs, reviewing and commenting on PRs, opening and commenting on issues, writing design docs, commenting on design docs, participating in mailing list discussions and participating in working groups. 62 | 63 | If Elekto fails to recognize you as eligible to vote in this election even though you believe you 64 | should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2025---TOC/exception) or [via an issue on the 65 | community repository](https://github.com/cloudfoundry/community/issues/new?assignees=&labels=election&template=request-to-be-elector-for-toc-election.md&title=Request+to+be+an+elector+for+TOC+election). 66 | 67 | Once the official election period starts, you will be able to rank the candidates in your preferred 68 | order and submit your ballot. You may set a password on your ballot, which is required to change 69 | your ballot later within the election period. Once the election period ends, all ballots are final. 70 | 71 | All ballot data for Elekto is stored on a database managed by the CFF staff, and is not shared with 72 | third parties. Individual ballot data is encrypted, and ballot data can be retrieved only in 73 | aggregate form. 74 | 75 | 76 | ## Election Results 77 | 78 | 79 | The newly elected body will be announced via cf-dev@lists.cloudfoundry.org on 26 Jun, 2024. 80 | 81 | 82 | Following the announcement, the voting results and winners will be published. 83 | -------------------------------------------------------------------------------- /elections/2025/TOC/election.yaml: -------------------------------------------------------------------------------- 1 | name: 2025 CFF Technical Oversight Committee election 2 | organization: Cloud Foundry Foundation 3 | start_datetime: 2025-06-12 06:59:00 # 11:59 pm PDT, 12 Jun 2025 4 | end_datetime: 2025-06-24 06:59:00 # 11:59 pm PDT, 24 Jun 2025 5 | no_winners: 3 6 | allow_no_opinion: True 7 | delete_after: True 8 | show_candidate_fields: 9 | - employer 10 | - github 11 | - slack 12 | election_officers: 13 | - beyhan 14 | - rkoster 15 | - christopherclark 16 | - ramiyengar 17 | - sgreenberg 18 | eligibility: Any individual who has contributed to any Cloud Foundry Foundation project in the twelve months prior to the election is eligible to vote in the TOC election. See [the voter eligibility section](https://github.com/cloudfoundry/community/blob/main/toc/TOC.md#community-eligibility-to-vote-in-toc-elections) for more information. 19 | exception_description: If you feel you are eligible to vote but are not represented in the list of voters, please request an exception to allow you to vote via the Elekto application. 20 | exception_due: 2025-06-22 06:59:00 # 11:59 pm PT, 22 Jun 2025 21 | -------------------------------------------------------------------------------- /elections/2025/TOC/election_desc.md: -------------------------------------------------------------------------------- 1 | The role of this election is to fill the three (3) seats due for election this year on the Cloud Foundry Foundation TOC. The elected members will serve two (2) year terms. This is a brief summary of the election; for more details, such as how to become a candidate, [see the README](https://github.com/cloudfoundry/community/tree/main/elections/2025/TOC#readme). 2 | 3 | ## Eligibility 4 | 5 | Anyone who has contributed to a Cloud Foundry Foundation project over the last year is eligible to vote. You will see either ELIGIBLE or NOT ELIGIBLE at the top of this screen. If Elekto fails to recognize you as eligible to vote in this election even though you believe you should be, please file a voting exception request [within the Elekto app](https://elections.cloudfoundry.org/app/elections/2025---TOC/exception) or via an issue on the community repository. The deadline for filing exceptions is June 20th, 11:59 pm PT. 6 | 7 | ## Schedule 8 | 9 | June 2: Election is announced and candidate nomination period begins 10 | June 12, 5:00 pm PDT: Candidate nomination period ends 11 | June 12, 11:59 pm PDT: Election begins 12 | June 24, 11:59 pm PDT: Election ends 13 | June 26: Announcement of results 14 | 15 | ## Changing Your Vote 16 | 17 | With Elekto, you may revoke and re-cast your ballot until the election deadline of June 24th. To do so, set a passphrase when you cast your ballot; as long as you have that passphrase, you may re-cast your ballot by returning to the site. 18 | -------------------------------------------------------------------------------- /orgs/.flake8: -------------------------------------------------------------------------------- 1 | [flake8] 2 | max-line-length = 140 3 | extend-ignore = E203 -------------------------------------------------------------------------------- /orgs/contributors.yml: -------------------------------------------------------------------------------- 1 | orgs: 2 | cloudfoundry: 3 | contributors: 4 | - a-b 5 | - a-hassanin 6 | - abg 7 | - acosta11 8 | - acrmp 9 | - adrianhoelzl-sap 10 | - agnello-noronha 11 | - ameowlia 12 | - anshrupani 13 | - anthonydahanne 14 | - ANUGRAHG 15 | - app-autoscaler-ci-bot 16 | - aqstack 17 | - aramprice 18 | - ard-wg-gitbot 19 | - arjun024 20 | - asalan316 21 | - Benjamintf1 22 | - beyhan 23 | - bgandon 24 | - Birdrock 25 | - blgm 26 | - bonzofenix 27 | - bosh-admin-bot 28 | - bosh-init-concourse 29 | - boyan-velinov 30 | - brayanhenao 31 | - bruce-ricard 32 | - bsoroushian 33 | - c0d1ngm0nk3y 34 | - ccjaimes 35 | - cf-buildpacks-eng 36 | - cf-bosh-ci-bot 37 | - cf-cli-eng 38 | - cf-final-release-election-bot 39 | - cf-frontend 40 | - cf-gitbot 41 | - cf-identity 42 | - cf-infra-bot 43 | - cf-rabbit-bot 44 | - cf-release-notes-bot 45 | - chaitanyamullangi 46 | - colins 47 | - coolgang123 48 | - Cryogenics-CI 49 | - ctlong 50 | - cunnie 51 | - dalvarado 52 | - Dariquest 53 | - danail-branekov 54 | - danielfor 55 | - davewalter 56 | - dennisjbell 57 | - dlresende 58 | - dmikusa 59 | - domdom82 60 | - Dray56 61 | - dsabeti 62 | - dsboulder 63 | - duanemay 64 | - ebroberson 65 | - emalm 66 | - emmjohnson 67 | - evanfarrar 68 | - FelisiaM 69 | - fhanik 70 | - FloThinksPi 71 | - fmoehler 72 | - ForestEckhardt 73 | - genevieve 74 | - geofffranks 75 | - georgethebeatle 76 | - Gerg 77 | - gm2552 78 | - Gourab1998 79 | - gururajsh 80 | - haochenhu233 81 | - hibell 82 | - hsinn0 83 | - iaftab-alam 84 | - ifindlay-cci 85 | - ikasarov 86 | - iprotsiuk 87 | - itsouvalas 88 | - IvanBorislavovDimitrov 89 | - ivanovac 90 | - jbooherl 91 | - jericop 92 | - jhvhs 93 | - joaopapereira 94 | - jochenehret 95 | - joefitzgerald 96 | - joergdw 97 | - johha 98 | - jrussett 99 | - julian-hj 100 | - kabathla 101 | - kathap 102 | - kehrlann 103 | - KesavanKing 104 | - kevin-ortega 105 | - kimago 106 | - klapkov 107 | - klaus-sap 108 | - kohara88 109 | - korifi-bot 110 | - krsna-m 111 | - krutten 112 | - lechnerc77 113 | - lnguyen 114 | - loewenstein-sap 115 | - Lokowandtg 116 | - MarcPaquette 117 | - mariash 118 | - max-soe 119 | - metric-store-ci 120 | - mingxiao 121 | - mkocher 122 | - MNoeva 123 | - modulo11 124 | - moggibear 125 | - moleske 126 | - mrosecrance 127 | - mvach 128 | - nader-ziada 129 | - nand2 130 | - norman-abramovitz 131 | - nouseforaname 132 | - ohkyle 133 | - oliver-heinrich 134 | - oppegard 135 | - paketo-bot 136 | - paketo-bot-reviewer 137 | - paulcwarren 138 | - pcf-core-services 139 | - PeteLevineA 140 | - peterhaochen47 141 | - philippthun 142 | - Pivotal-Christopher-Wong 143 | - pivotal-david-osullivan 144 | - pivotal-marcela-campo 145 | - pivotalgeorge 146 | - plowin 147 | - pyogesh2 148 | - radito3 149 | - ragaskar 150 | - rajathagasthya 151 | - ramonskie 152 | - reedr3 153 | - RichardJJG 154 | - rlewis24 155 | - robdimsdale 156 | - rroberts2222 157 | - ryanwittrup 158 | - s-yonkov-yonkov 159 | - saloni-sshah 160 | - salzmannsusan 161 | - samze 162 | - Sascha-Stoj 163 | - selzoc 164 | - services-api-ci 165 | - servicesenablement 166 | - sethboyles 167 | - shilpachandrashekara 168 | - shrisha-c 169 | - silvestre 170 | - snneji 171 | - Soha-Albaghdady 172 | - sophiewigmore 173 | - spgreenberg 174 | - sp1goyal 175 | - ssunka 176 | - stefanlay 177 | - sthielke 178 | - strehle 179 | - stuclem 180 | - svcboteos 181 | - svkrieger 182 | - swalchemist 183 | - tack-sap 184 | - Tallicia 185 | - tas-runtime-bot 186 | - tcdowney 187 | - ten4o 188 | - theghost5800 189 | - tnikolova82 190 | - tomkennedy513 191 | - torsten-sap 192 | - totherme 193 | - uzabanov 194 | - vipinvkmenon 195 | - vkalapov 196 | - VRBogdanov 197 | - wayneeseguin 198 | - weili-broadcom 199 | - WeiQuan0605 200 | - weresch 201 | - winkingturtle-vmw 202 | - xandroc 203 | - xiujiao 204 | - xtreme-conor-nosal 205 | - xtreme-nitin-ravindran 206 | - xtremerui 207 | - Yavor16 208 | - stiv03 209 | - ystros 210 | - ZPascal 211 | - zucchinidev 212 | - nookala 213 | - joeeltgroth 214 | - jajita 215 | - hamideh-amini-khezrabad 216 | - Milena-Encheva 217 | - AttilaAlmasi 218 | - dtasSap 219 | -------------------------------------------------------------------------------- /orgs/generate_working_group_projects_sync_config.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | set -eu -o pipefail 4 | 5 | repo_root=$(dirname $(cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd)) 6 | 7 | $repo_root/toc/working-groups/parsable-working-groups.sh | \ 8 | jq 'map(select(.config | has("github_project_sync"))) | 9 | map( 10 | .name as $name | 11 | .areas as $areas | 12 | .config.github_project_sync.mapping | to_entries | map({org: .key, project_id: .value}) | 13 | map(.org as $org | { 14 | project: {organization: $org, number: .project_id}, 15 | repositories: $areas | map( 16 | .name as $area | 17 | .repositories | map(select(startswith("\($org)/"))) | map({ 18 | name: ., 19 | fields: [ 20 | {name: "Last Activity", type: "last_activity"}, 21 | {name: "Status", type: "default_single_select", value: "Inbox"}, 22 | {name: "Submitter", type: "author"}, 23 | {name: "Draft", type: "draft"}, 24 | {name: "Area", type: "single_select", value: $area}, 25 | {name: "Type", type: "type"}, 26 | {name: "Changes", type: "changes"} 27 | ] 28 | }) 29 | ) | flatten 30 | }) 31 | ) 32 | ' | jq -cs 'flatten' 33 | -------------------------------------------------------------------------------- /orgs/orphaned_repos.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | set -eu -o pipefail 4 | 5 | comm -3 <(cat org/orgs.yml | spruce json \ 6 | | jq -r '.orgs.cloudfoundry.repos | with_entries(select(.value.archived != true)) | keys | map("cloudfoundry/\(.)") | sort | unique | .[]') \ 7 | <(./toc/working-groups/parsable-working-groups.sh \ 8 | | jq -s -r 'map(map(.areas[].repositories)) | flatten | map(select(contains("cloudfoundry"))) | sort | unique | .[]') 9 | -------------------------------------------------------------------------------- /orgs/pyproject.toml: -------------------------------------------------------------------------------- 1 | [tool.black] 2 | line-length = 140 -------------------------------------------------------------------------------- /orgs/requirements-dev.txt: -------------------------------------------------------------------------------- 1 | black 2 | flake8 3 | flake8-bugbear 4 | flake8-black -------------------------------------------------------------------------------- /orgs/requirements.txt: -------------------------------------------------------------------------------- 1 | pyyaml 2 | jsonschema 3 | requests -------------------------------------------------------------------------------- /toc/ADMIN.md: -------------------------------------------------------------------------------- 1 | ## Charter 2 | 3 | The staff of the Cloud Foundry Foundation (a directed fund of the Linux Foundation) and staff of other relevant Linux Foundation departments 4 | maintain the following repositories. 5 | 6 | 7 | ## Scope 8 | 9 | - Administrative tools and applications 10 | - Training and certifications materials 11 | - Logos and other intellectual property assets 12 | - Other technical asssets in the cloudfoundry GitHub organization that do not fall under the purview of the TOC or Working Groups 13 | 14 | 15 | ## Roles & Technical Assets 16 | 17 | ```yaml 18 | name: Admin 19 | execution_leads: 20 | - name: The Linux Foundation 21 | github: thelinuxfoundation 22 | - name: Chris Clark 23 | github: christopherclark 24 | - name: Ram Iyengar 25 | github: ramiyengar 26 | technical_leads: [] 27 | bots: [] 28 | areas: 29 | - name: Admin 30 | approvers: [] 31 | repositories: 32 | - cloudfoundry/admin-tools 33 | - cloudfoundry/cf-slackin 34 | - cloudfoundry/cfcd-broker 35 | - cloudfoundry/cfcd-cert-items 36 | - cloudfoundry/cfcd-ci 37 | - cloudfoundry/cfcd-course-content 38 | - cloudfoundry/cfcd-dockerfile 39 | - cloudfoundry/cfcd-exam-info 40 | - cloudfoundry/cfcd-facts 41 | - cloudfoundry/cfcd-items 42 | - cloudfoundry/cfcd-mappings 43 | - cloudfoundry/cfcd-mindmaps 44 | - cloudfoundry/cfcd-parser 45 | - cloudfoundry/cfcd-prep 46 | - cloudfoundry/cff-platform-certification 47 | - cloudfoundry/dev-cert 48 | - cloudfoundry/dev-cert-grading 49 | - cloudfoundry/developer-training-class-apps 50 | - cloudfoundry/developer-training-class-site 51 | - cloudfoundry/developer-training-course 52 | - cloudfoundry/developer-training-hugo-parser 53 | - cloudfoundry/foundation 54 | - cloudfoundry/go-fetcher 55 | - cloudfoundry/lf-elearning 56 | - cloudfoundry/logos 57 | - cloudfoundry/oss-summit-class 58 | - cloudfoundry/platform-certification 59 | - cloudfoundry/slack-interrupt-bot 60 | - cloudfoundry/summit-hands-on-labs 61 | - cloudfoundry/summit-training-classes 62 | - cloudfoundry/training-cert-admin 63 | 64 | - name: CF Homebrew TAP 65 | approvers: 66 | - name: Al Berez 67 | github: a-b 68 | - name: Shwetha Gururaj 69 | github: gururajsh 70 | - name: João Pereira 71 | github: joaopapereira 72 | - name: Sam Gunaratne 73 | github: samze 74 | - name: Aram Price 75 | github: aramprice 76 | - name: Brian Upton 77 | github: ystros 78 | - name: Chris Selzo 79 | github: selzoc 80 | - name: Diego Lemos 81 | github: dlresende 82 | - name: George Blue 83 | github: blgm 84 | - name: Iain Findlay 85 | github: ifindlay-cci 86 | - name: Konstantin Kiess 87 | github: nouseforaname 88 | - name: Konstantin Semenov 89 | github: jhvhs 90 | - name: Long Nguyen 91 | github: lnguyen 92 | - name: Rajan Agaskar 93 | github: ragaskar 94 | bots: 95 | - name: CF CLI Eng 96 | github: cf-cli-eng 97 | - name: Credhub CLI 98 | github: credhub-ci-bot 99 | repositories: 100 | - cloudfoundry/homebrew-tap 101 | config: 102 | github_project_sync: 103 | mapping: 104 | cloudfoundry: 31 105 | ``` 106 | -------------------------------------------------------------------------------- /toc/CHANGEPLAN.md: -------------------------------------------------------------------------------- 1 | # Governance Evolution 2 | 3 | ## Approach 4 | 5 | The general approach to transitioning from the existing Cloud Foundry 6 | Foundation technical governance process to the new process is to start 7 | with the Technical Oversight Committee (TOC) and then allow that new TOC 8 | to work through the details of restructuring the community. 9 | 10 | It will be critically important that existing technical community members, 11 | and especially technical community leaders, continue their work on the 12 | projects during the transition process. 13 | 14 | We believe that the community will work together with the right intentions 15 | during this transition period. When in doubt, community members should 16 | refer to the newly documented [principles](./PRINCIPLES.md) to guide their 17 | decisions. 18 | 19 | ## TOC Formation 20 | 21 | ### Governing Board Approval 22 | 23 | The TOC structure must be approved by the Cloud Foundry Foundation 24 | Governing Board. Once approved, the technical community can proceed 25 | with it's reorganization, led by a newly elected TOC. 26 | 27 | ### Initial TOC Eligibility 28 | 29 | The rules for eligibility to be a member of the TOC include specific 30 | roles, which do not exist at the time of the first election. As such, 31 | eligibility to be nominated for the TOC during the first election will 32 | be defined as: 33 | 34 | * Community members who are PMC Leads, Project Leads or committers within 35 | any PMC or project. Each member organization of the CFF can also nominate 36 | one additional person not meeting these criteria as a candidate for the 37 | first TOC election. 38 | 39 | ### Initial TOC Election Voter Eligibility 40 | 41 | The rules for eligibility to vote in a TOC election will apply to the 42 | first election, but will explicitly include all community members that 43 | are PMC Leads, Project Leads or committers within any PMC or project. 44 | 45 | ### Initial TOC Terms 46 | 47 | The first TOC election will be structured to elect five TOC members. Using 48 | the results of the election, the two nominees with the highest number of 49 | votes will have two year terms. The next three nominees, by number of votes, 50 | will have an initial term of one year. 51 | 52 | The second TOC election will be held a year after the initial election. During 53 | that second election cycle, the three TOC members with initial one year terms 54 | will be at the end of their initial terms. Those TOC seats will be up for election 55 | during that second TOC election. 56 | 57 | ### First TOC Meeting 58 | 59 | Once the election is complete, the newly formed TOC will meet. During that 60 | meeting, the following must be addressed: 61 | 62 | 1) Selection of a TOC Chair 63 | 2) Schedule for ongoing TOC meetings 64 | 65 | Beyond that, the TOC will need to begin the process of completing the technical 66 | governance restructring process. 67 | -------------------------------------------------------------------------------- /toc/PRINCIPLES.md: -------------------------------------------------------------------------------- 1 | # Principles 2 | 3 | The following are the principles that guide the development and evolution of the Cloud Foundry community's technical governance. The overarching goal is to get and keep a healthy CF community. 4 | 5 | ## Transparency 6 | We want community decisions to be proposed, evaluated and made in a manner that is fully transparent to any member of the community. 7 | In particular, this means that all parts of the Cloud Foundry technical community (especially the TOC, working groups and sub-working groups) should aim for transparent communication and decision making (e.g. with Meeting Notes, Feature Proposals, Deprecation Plans, or Architecture Decision Records), publish their roadmap (as applicable and appropriate, e.g. as a GitHub Project), and have/participate in public and recorded meetings. 8 | 9 | This will ensure equal access to information about past decisions, current activities and future plans. The sole exception is security issue management. 10 | 11 | ## Clarity 12 | We want the community's rules (on all levels) to be documented and published in a way that provides easy and clear access. 13 | In particular, this means that the community's structure and rules for technical governance, including any deviations or additions for working groups or sub-working groups are written in markdown and published (or linked to) in this repository. 14 | 15 | This will ensure that any interested party can understand how and where decisions are made and how to participate in the decision making or execution. 16 | 17 | ## Inclusivity 18 | We want the community to be inclusive and approachable for any willing and qualified participants. 19 | In particular, this means that there is a clear and documented path to contributions and participation. 20 | 21 | This will ensure that we foster a diverse community of users, contributors and committers. 22 | 23 | --- 24 | Being transparent, clear and inclusive does not mean saying yes to every proposal, contribution or comment - saying no after careful consideration of all relevant input can indeed be very important. 25 | The rules have to be clear and non-discriminating and the careful consideration should be made in the open though. 26 | -------------------------------------------------------------------------------- /toc/elections/2021/README.md: -------------------------------------------------------------------------------- 1 | The 2021 CFF TOC election guide has been moved to [`elections/2021/TOC/README.md`](../../../elections/2021/TOC/README.md). 2 | -------------------------------------------------------------------------------- /toc/elections/2021/results.md: -------------------------------------------------------------------------------- 1 | The 2021 CFF TOC election results have been moved to [`elections/2021/TOC/results.md`](../../../elections/2021/TOC/results.md). 2 | -------------------------------------------------------------------------------- /toc/elections/2021/voters.md: -------------------------------------------------------------------------------- 1 | The 2021 TOC election voter list has been moved to [`elections/2021/TOC/voters.md`](../../../elections/2021/TOC/voters.md). 2 | -------------------------------------------------------------------------------- /toc/elections/2022/Readme.md: -------------------------------------------------------------------------------- 1 | The 2022 CFF TOC election guide has been moved to [`elections/2022/TOC/README.md`](../../../elections/2022/TOC/README.md). 2 | -------------------------------------------------------------------------------- /toc/rfc/archived/rfc-0005-github-teams-and-access.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Standardizing Github Teams and Access 4 | - Start Date: 2022-02-28 5 | - Author(s): @ameowlia 6 | - Status: Superseded by [community#375](https://github.com/cloudfoundry/community/pull/375) 7 | - RFC Pull Request: [community#170](https://github.com/cloudfoundry/community/pull/170) 8 | 9 | 10 | ## Summary 11 | 12 | All working groups SHOULD create GitHub teams using the standardized name format. 13 | 14 | ## Problem 15 | 16 | CFF technical governance has changed to be organized around working groups and 17 | new roles like Tech Lead and Approver. Most working groups also have sub-groups. 18 | 19 | We need ways within the community to: 20 | * Provide the team members with proper push access to certain repos, 21 | * Provide a way for others to tag groups of people. 22 | 23 | ## Proposal 24 | 25 | Every working group SHOULD make GitHub teams within the `cloudfoundry` org to reflect the following groups. 26 | 27 | | Name of Team | Team Membership | Permissions | 28 | |---|---|---| 29 | | toc | Technical Oversight Committee | Admin access to everything | 30 | | wg-leads | Tech and Execution Leads for all WGs | Write access to community repo | 31 | | wg-[WORKING-GROUP-NAME] | All approvers and leads for a WG | None: only for organization and tagging | 32 | | wg-[WORKING-GROUP-NAME]-leads | All leads for a WG | Admin access for all WG repos | 33 | | wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers | Approvers & tech leads for an area within a WG | Write access for all repos in the area | 34 | | wg-[WORKING-GROUP-NAME]-bots | Bot accounts for a WG | Write access for all WG repos | 35 | 36 | Where: 37 | * `WORKING-GROUP-NAME` is the name of the Working Group, converted to kebab case, 38 | * `AREA-NAME` is the name of the area, also converted to kebab case, or a suitable short name that identifies it clearly and uniquely within the Working Group. 39 | -------------------------------------------------------------------------------- /toc/rfc/assign-rfc-number.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | 3 | set -e 4 | set -u 5 | set -o pipefail 6 | 7 | script_dir="$(cd $(dirname "$BASH_SOURCE[0]") && pwd)" 8 | 9 | #### 10 | # CONFIG 11 | # 12 | 13 | DEBUG=${DEBUG:-} 14 | 15 | if [[ "${DEBUG}" ]] ; then 16 | set -x 17 | fi 18 | 19 | RFC_MERGE_COMMITISH=${1:-} 20 | if [[ -z "${RFC_MERGE_COMMITISH}" ]] ; then 21 | >&2 echo "RFC merge commit SHA is required argument to execute the script. The SHA is needed to identify the RFC PR number." 22 | exit 1 23 | fi 24 | 25 | OWNER=${OWNER:-cloudfoundry} 26 | REPO=${REPO:-community} 27 | MAIN_BRANCH=${MAIN_BRANCH:-main} 28 | NOPUSH=${NOPUSH:-} 29 | 30 | #### 31 | # FUNCTIONS 32 | # 33 | 34 | generate_id() { 35 | id="$(find "$script_dir" -maxdepth 2 -type f -exec basename {} \; | grep -E '^rfc-[0-9]{4}-' | sed 's/[^0-9]*//' | sed -E 's|^([[:digit:]]{4})-.*$|\1|' | sort | tail -n 1 | sed 's/^0*//')" 36 | ((id++)) 37 | printf "%04d" "${id}" 38 | } 39 | 40 | require_command() { 41 | if ! [ -x "$(command -v ${1})" ]; then 42 | echo "Error: '${1}' is not installed." >&2 43 | exit 1 44 | fi 45 | } 46 | 47 | #### 48 | # DEPENDENCIES 49 | # 50 | 51 | require_command git 52 | require_command awk 53 | require_command grep 54 | require_command sed 55 | require_command jq 56 | require_command curl 57 | 58 | #### 59 | # TASK 60 | # 61 | 62 | 63 | REPOBASENAME=$(git config --get remote.origin.url | sed -nr 's/^(https|git)(:\/\/|@)([^\/:]+)[\/:]([^\/:]+)\/(.+).git$$/\4\/\5/p') 64 | REPOOWNER=$(git config --get remote.origin.url | sed -nr 's/^(https|git)(:\/\/|@)([^\/:]+)[\/:]([^\/:]+)\/(.+).git$$/\4/p') 65 | REPONAME=$(git config --get remote.origin.url | sed -nr 's/^(https|git)(:\/\/|@)([^\/:]+)[\/:]([^\/:]+)\/(.+).git$$/\5/p') 66 | ISAFORK=$(curl -s https://api.github.com/repos/${REPOOWNER}/${REPONAME} | jq '.fork') 67 | UPSTREAMSET=$((git remote -v | grep upstream) || echo "") 68 | 69 | if [[ "$ISAFORK" = true ]] ; then 70 | if [[ -z "$UPSTREAMSET" ]] ; then 71 | git remote add upstream https://github.com/${OWNER}/${REPO}.git 72 | fi 73 | git fetch upstream 74 | git checkout ${MAIN_BRANCH} 75 | git merge upstream/${MAIN_BRANCH} 76 | fi 77 | 78 | echo "> Pulling latest changes...." 79 | git pull origin ${MAIN_BRANCH} --rebase 80 | 81 | # check that the identified merge commit is a 2-parent merge commit 82 | num_parents=$(git cat-file commit "${RFC_MERGE_COMMITISH}" | grep ^parent | wc -l) 83 | 84 | if [[ "$num_parents" -ne 2 ]]; then 85 | commit_sha=$(git rev-parse "${RFC_MERGE_COMMITISH}") 86 | >&2 echo "Error: commit-ish '${RFC_MERGE_COMMITISH}' selected as RFC merge commit (with SHA ${commit_sha}) has $num_parents parents, not 2" 87 | exit 2 88 | fi 89 | 90 | # lists all pull request HEADs and greps for the second parent of the RFC merge commit which is the RFC PR HEAD to get the PR number 91 | PR_NUMBER=$(git ls-remote origin 'pull/*/head' | grep -F -f <(git rev-parse "${RFC_MERGE_COMMITISH}^2") | awk -F'/' '{print $3}') 92 | 93 | RFC_ID=$(generate_id) 94 | echo "> Generated RFC number: ${RFC_ID}" 95 | 96 | 97 | SOURCE_DOC=$(find "${script_dir}" -maxdepth 2 -type f -name 'rfc-draft-*') 98 | TARGET_DOC=${SOURCE_DOC//rfc-draft/rfc-${RFC_ID}} 99 | SOURCE_DIR=$(find "${script_dir}" -maxdepth 2 -type d -name 'rfc-draft-*') 100 | TARGET_DIR=${SOURCE_DIR//rfc-draft/rfc-${RFC_ID}} 101 | 102 | echo "> Transforming '${SOURCE_DOC}' into '${TARGET_DOC}'" 103 | sed \ 104 | -e "s|- RFC Pull Request:.*|- RFC Pull Request: [${REPO}#${PR_NUMBER}](https://github.com/${OWNER}/${REPO}/pull/${PR_NUMBER})|" \ 105 | -e "s|- Status:.*|- Status: Accepted|" \ 106 | -e "s|rfc-draft-|rfc-${RFC_ID}-|" \ 107 | "${SOURCE_DOC}" \ 108 | > "${TARGET_DOC}" 109 | 110 | echo "> Adding '${TARGET_DOC}'..." 111 | git add "${TARGET_DOC}" 112 | 113 | echo "> Removing '${SOURCE_DOC}'..." 114 | git rm "${SOURCE_DOC}" 115 | 116 | if [[ "$SOURCE_DIR" ]] ; then 117 | echo "> Moving ${SOURCE_DIR} to ${TARGET_DIR}..." 118 | git mv "${SOURCE_DIR}" "${TARGET_DIR}" 119 | fi 120 | 121 | echo "> Committing to '${MAIN_BRANCH}'..." 122 | git commit -m "Assigning number ${RFC_ID} to RFC from PR #${PR_NUMBER}" 123 | 124 | if [[ -n "${NOPUSH}" ]] ; then 125 | echo "> *NOT* pushing to '${MAIN_BRANCH}' automatically!" 126 | echo "> *** Push to '${MAIN_BRANCH}' after verifying RFC number and status changes ***" 127 | else 128 | echo "> Pushing to '${MAIN_BRANCH}'..." 129 | git push 130 | fi 131 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0001-jammy-os.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Move to Jammy Jellyfish (22.04) as the next CF Linux Operating System after Bionic. 4 | - Start Date: 2022-01-22 5 | - Author(s): @dsboulder @rkoster 6 | - Status: Accepted 7 | - RFC Pull Request: https://github.com/cloudfoundry/community/pull/191 8 | 9 | ## Summary 10 | 11 | Since bionic is expiring in April of 2023, the CF community needs to switch to a new ubuntu version by then. 12 | Changing operating systems is fairly expensive and we should perform a coordinated move to Jammy Jellyfish Ubuntu 22.04 in order to maximize our runway. 13 | 14 | ## Problem 15 | 16 | The CF ecosystem has undergone a few expensive operation system transitions in the last 8 years. This proposal covers an aggressive plan to skip Ubuntu Focal, and instead execute a rapid move to the upcoming 22.04 release (codename Jammy) by the end of 2022. There are many moving parts in upgrading from Ubuntu 18.04 (codename Bionic) and this document covers what it would take to move them all to Ubuntu 22.04 before community 18.04 support ends in April 2023. 17 | 18 | ## Proposal 19 | 20 | Execute a coordinated cross-component move to Jammy Jellyfish, starting in March or April of 2022. The move affects many components and groups, here's the approximate supply chain propagation: 21 | ![Jammy supply chain](rfc-0001-jammy-os/jammy-jellyfish-cf-supply-chain.png) 22 | 23 | The tasks break down below: 24 | 25 | ### Produce new stemcells for all IaaSes 26 | *The Foundational Infrastructure Working Group* owns the responsibility for making new stemcells. We expect to be able to consume GA-quality JJ packages from canonical sometime in the month of April, 2022. We might consider doing some early experimentation with 21.10 (impish) or 20.04 (focal) in order to fix some of the expected upcoming breaking changes with JJ, mainly to mitigate timeline risk. 27 | 28 | @rkoster owns this operation and can provide any details needed on the BOSH side. Target start time: March 2022 29 | 30 | ### Produce new cflinuxfs4 rootfs for containers 31 | The production of cflinuxfs4 belongs to the *App Runtime Interfaces Working Group*. It's not clear yet if cflinuxfs4 can run workloads on the bionic kernel, so there may be a dependency on a JJ stemcell to truly validate the new stack. 32 | 33 | @meyer owns this operation and can provide details needed on the buildpacks/rootfs side. 34 | Target start time: March 2022 35 | 36 | ### Create new buildpack versions that are compatible with cflinuxfs4 37 | The creation of a new set of cflinuxfs4-compatible buildpacks, which are hopefully very similar to the existing buildpacks, belongs to the *App Runtime Interfaces Working Group*. This could be an opportunity to switch to some implementation of Cloud Native Buildpacks, but we run the risk of exceeding the bionic timeline by extending the scope. 38 | 39 | @meyer owns this operation and can provide details needed on the buildpacks/rootfs side. 40 | Target start time: April 2022 41 | 42 | ### Ensure all CF components are compatible with new stemcells, fix them as needed 43 | Many CF components should run unmodified on the new Operating System, but there are always some that need work. Some job control scripts typically end up executing OS-specific operations, any kernel performance tweaks need to be reassessed (gorouter!), and low-level jobs like garden typically need modification to be compatible. 44 | 45 | This work should be driven out by the CF-deployment conversion work, with *relevant working groups* fixing incompatibility issues when discovered. 46 | Target start time: June 2022 (using early stemcell builds) 47 | 48 | ### Create a final cf-deployment distribution based on 22.04 49 | There is no owner identified for this work, but final validation would fall into the App Deployments Working Group (with other WGs fixing release incompatibility issues) 50 | Target verification time: August 2022 51 | 52 | ### Fix application incompatibilities 53 | Because a parallel set of buildpack will exist for cflinuxfs4, applications can move over at their leisure and fix incompatibilities along the way. 54 | Target finishing time: April 2023, when Bionic community support ends! 55 | 56 | ### Ensure all applications have moved over 57 | The final step is for operators to find outlying applications that haven't yet made the switch. The CF stack auditor plugin will assist with that, like last time. We are also likely going to make it easier to continue to run cflinuxfs3 stacks past 2023, either in an insecure or extended-support way, for operators that haven't finished getting all applications to move over. 58 | Target finishing time: April 2023, when Bionic community support ends! 59 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0001-jammy-os/jammy-jellyfish-cf-supply-chain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/community/3e9889fc3835b5457b325656c4e59c7d196d3162/toc/rfc/rfc-0001-jammy-os/jammy-jellyfish-cf-supply-chain.png -------------------------------------------------------------------------------- /toc/rfc/rfc-0002-github-members.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Who is able to add and remove members of CFF Github Orgs 4 | - Start Date: 2022-01-26 5 | - Author(s): @LeePorte 6 | - Status: Accepted 7 | - RFC Pull Request: https://github.com/cloudfoundry/community/pull/194 8 | 9 | 10 | ## Summary 11 | 12 | Working group leads and approvers are the primary roles responsible for 13 | granting GitHub users membership to the CFF Github Orgs, as they have 14 | the most context on which users within the community meet the criteria to be 15 | regular contributors. 16 | 17 | The TOC is the body responsible for removing an existing member from the CFF 18 | Github Orgs and coordinating with working groups to ensure that the removal 19 | does not have unexpected consequences. 20 | 21 | ## Problem 22 | 23 | Under the previous dojo-based participation model, a central team of VMware 24 | admins was primarily responsible for managing the members of the CFF Github 25 | Orgs . In the current system of CF community roles and responsibilities, 26 | however, that delegation to the administrative team of a single member company 27 | no longer makes sense. 28 | 29 | ## Proposal 30 | 31 | As defined in the 32 | [roles](https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md), each 33 | Contributor should be a member of the appropriate CFF Github Org(s). The leads 34 | and approvers within a Working Group are best positioned to decide whether an 35 | individual has met the minimum contribution criteria to become an official 36 | contributor. 37 | 38 | A Working Group approver or lead should raise a [PR on the community 39 | repository](https://github.com/cloudfoundry/community/pulls) to propose adding 40 | a new member to a CFF Github Org. This PR should add the member directly to the 41 | file in the [organizational structure 42 | directory](https://github.com/cloudfoundry/community/tree/main/org) that 43 | contains the list of contributors. Automation will periodically synchronize the 44 | GitHub org membership with the files in this directory. Only Working Group 45 | leads and the TOC will actually have permission to merge these PRs under the 46 | planned access control on the community repository. 47 | 48 | As removing a member from a CFF GitHub Org may have unintended consequences 49 | across the organization, the TOC is the body required to approve those 50 | removals. Proposals to remove a member should also be submitted via PR, and the 51 | submitter should tag the PR with `toc` and should mention `@cloudfoundry/toc` 52 | to make the TOC aware of the request. The TOC will then consult any working 53 | groups that may be affected by the removal of this member and use its usual 54 | decision process to approve or reject the removal. 55 | 56 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0003-pr-only-workflow.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Move to a PR Only Workflow 4 | - Start Date: 2022-02-28 5 | - Author(s): @ameowlia 6 | - Status: Accepted 7 | - RFC Pull Request: [community#171](https://github.com/cloudfoundry/community/pull/171) 8 | 9 | 10 | ## Summary 11 | 12 | By default, all repos SHOULD require PRs for changes. 13 | 14 | ## Problem 15 | 16 | It is near impossible for community members to know what is being worked on and 17 | why changes are being made. This makes it difficult for anyone to join our 18 | community or for anyone to try to do code archeology. 19 | 20 | ## Proposal 21 | 22 | All repos SHOULD: 23 | * have branch protection to prevent any direct committing to the default branch(es). 24 | * require changes must be submitted as a PR. 25 | * require one approver review and approve the code via github reviews. 26 | 27 | **Happy path workflow** 28 | 1. A community member makes a PR. 29 | 1. An approver uses github reviews and approves the change. 30 | 1. The approver merges the PR. 31 | 32 | **Github Setup** 33 | 34 | To enable this, each repo will require the following branch protections for their default branch(es): 35 | * "Require a pull request before merging": checked 36 | * "Require approvals": checked 37 | * "Required number of approvals before merging": 1 38 | 39 | 40 | 41 | ## FAQ 42 | 43 | **What if the pipeline is red?** 44 | Just because a PR has been approved does not mean it will be merged right away. 45 | Approvers SHOULD aim to merge PRs as quickly as is safe to do so, but reserve the 46 | right to not merge PRs right away. 47 | 48 | **What if the PR breaks the pipeline?** 49 | Whoever diagnoses the broken pipeline SHOULD alert the PR author and, if they 50 | have permission, they SHOULD revert the PR. If they don’t have permission to 51 | revert they SHOULD ask the original reviewer to revert or submit a PR to revert 52 | so another approver can merge. 53 | 54 | **Can a PR author review their own PR?** 55 | No. Github does not let you review your own PRs. So even if you are a Working 56 | Group approver you will need another approver to review your PR. We can change 57 | this if it is a burden. 58 | 59 | **What about bots?** 60 | Some teams have bots (like dependabot) that currently make a PR, wait for checks 61 | to pass, and then merge their own PR. With this review proposal that will no 62 | longer be possible. To continue with a fully automated workflow a repo MAY use 63 | a **two bot** workflow. Have one bot for making PRs (dependabot) and one for 64 | merging them (mergebot). This is similar to the Istio and Kubernetes processes. 65 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0004-wg-visibility.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Roadmap Visibility Expectations 4 | - Start Date: 2022-02-23 5 | - Author(s): @rkoster, @ameowlia, @geofffranks 6 | - Status: Accepted 7 | - RFC Pull Request: [community#173](https://github.com/cloudfoundry/community/pull/173) 8 | 9 | 10 | ## Summary 11 | 12 | We wish to provide a common format for working groups to provide visibility into work 13 | currently in progress for repos, PR/Issue review, and roadmaps. This should make it 14 | easier for external parties to view priorities and progress in things they're interested in, 15 | and help build a bigger sense of community. 16 | 17 | ## Problem 18 | 19 | There is a gap in visibility into issues/PRs that are being worked on, as well as new 20 | features under development. Much of this work/discussion/prioritization is done 21 | internally within different companies, and community members have a difficult time 22 | understanding what’s happening, or if they’ve opened a request to a repo that no one 23 | is watching. 24 | 25 | ## Proposal 26 | 27 | ### High Level Solution 28 | - Provide GitHub Project per Working Group for tracking PR status + issue status + prioritization 29 | - Encourage Slack integration on issue and PR creation for repos 30 | - Provide GitHub Project per Working Group for large technical proposals/new feature RFCs 31 | - Adopt the PR-only workflow on repos via automation 32 | - Encourage weekly review/triage of issues and PRs for each Working Group 33 | 34 | ### Solution Details 35 | 36 | #### Create a config file to iterate Working Groups, areas, and their repos 37 | - Can be used to automate access control for teams, enforce branch restrictions, etc. 38 | - Would be located at `cloudfoundry/community/toc/working-groups/wg-configs.yml` 39 | 40 | #### Provided GitHub Projects 41 | - Make use of terraform integrations and a GitHub action on the `cloudfoundry/community` 42 | repo to create/manage projects, columns, and an ongoing GitHub action that will 43 | add the cards to projects. 44 | - This can be configured to create projects on a per-WG basis, or per WG-area 45 | basis as needed 46 | 47 | #### Provided Slack Integration Instructions 48 | - Provide a doc in the `cloudfoundry/community` repo detailing how to set up the 49 | GitHub slack app integration. 50 | 51 | ### FAQ 52 | 53 | #### Does my Working Group have to use these? 54 | No, terraforming of repos would be opt-in by editing a configuration file in the 55 | community repo. 56 | 57 | #### Do we have to use the default project columns? 58 | No, the action making cards for the project only needs a column ID to place 59 | cards initially. If you want to bring-your-own project, that’s fine. 60 | 61 | #### What about GitHub Projects’ 25-repo single-org limitation? 62 | We’re using terraform to populate the cards initially, rather than the built in 63 | issue/project integration, which lets us get around this limitation. TF won’t 64 | manage the cards otherwise until the PR is closed. In the long term we will move 65 | to GitHub's new style projects which remove this limitation. 66 | 67 | #### Why use a GitHub Project for proposals? 68 | Teams might use a variety of solutions for writing proposals (Google docs, GitHub 69 | repos with markdown docs + PRs, long-lived GitHub Issues, internal project-management 70 | tools). Having each Working Group utilize a GitHub project with cards linking to the underlying 71 | proposals gives the community a consistent experience for finding out what’s going on. 72 | 73 | #### Why are there different projects for proposals vs PRs? 74 | Chances are there will be different swimlanes for proposals, rather than PRs, 75 | and the noise of both in a single board may be troublesome. 76 | 77 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0006-approver-requirements.md: -------------------------------------------------------------------------------- 1 | ## Meta 2 | [meta]: #meta 3 | - Name: Approver Requirements 4 | - Start Date: 2022-04-08) 5 | - Author(s): @ameowlia, @ctlong 6 | - Status: Accepted 7 | - RFC Pull Request: [community#244](https://github.com/cloudfoundry/community/pull/244) 8 | 9 | ## Summary 10 | 11 | Change the requirements for nominating an Approver to allow for a wider range of 12 | contributions to be accepted. 13 | 14 | ## Problem 15 | 16 | The current criteria that must be met in order to be nominated as an approver 17 | are very narrow. Not every working group receives PRs frequently, providing 18 | scant opportunity for folks to review them in order to be considered for 19 | nomination as an approver. Additionally, other valuable functions within working 20 | groups (ie. reviewing Issues, answering Slack questions, etc.) are ignored as 21 | options to be considered for nomination. 22 | 23 | ## Proposal 24 | 25 | We want to consider a wider range of engagement for consideration when 26 | nominating approvers. This RFC proposes to change the [language in the approver 27 | requirements](https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md#requirements-2) 28 | to the following: 29 | 30 | **Requirements** 31 | * Be a reviewer for at least 3 months 32 | * Have completed at least 20 of the following 33 | * Submitted a substantial PR 34 | * Reviewed a substantial PR 35 | * Submitted a substantial Issue 36 | * Reviewed a substantial Issue 37 | * Involved in technical discussion. This includes, but is not limited to, 38 | being involved in technical decision making in proposals or resolving 39 | interrupts in slack. 40 | * Nominated by a WG lead (with no objections from other leads). 41 | 42 | A substantial PR is anything that changes the logic of the code or introduces a 43 | complex amount of documentation. The following are examples of substantial PRs: 44 | bug fixes, features, large docs changes like creating a new debugging document 45 | or new architecture diagram. The following are examples of non-substantial PRs: 46 | dependabot PRs or small docs changes like fixing typos or reorganizing content. 47 | 48 | A substantial Issue is anything that requires knowledge of the codebase. The 49 | following are examples of substantial Issues: feature requests, bug write ups, 50 | debugging help requests. The following are examples of non-substantial Issues: 51 | minor doc change requests. 52 | 53 | A technical discussion is a thread on slack or in GitHub that requires knowledge 54 | of the codebase. The following are examples of technical discussions that will 55 | be considered: resolving interrupts in slack, or commenting on proposals. 56 | Technical discussions are counted per-thread, not per-message. 57 | 58 | The WG lead has final say if an issue, PR, or discussion is considered 59 | substantial. 60 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0008-role-change-process.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Role Change Process 4 | - Start Date: 2022-04-13 5 | - Author(s): @gerg 6 | - Status: Accepted 7 | - RFC Pull Request: [community#248](https://github.com/cloudfoundry/community/pull/248) 8 | [https://github.com/cloudfoundry/community/pull/248](https://github.com/cloudfoundry/community/pull/248) 9 | 10 | 11 | ## Summary 12 | 13 | Define the process for granting or revoking roles. 14 | 15 | ## Problem 16 | 17 | There are currently 18 | [descriptions](https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md) 19 | for the criteria necessary to become a Contributor or Approver. It is not 20 | currently defined how people apply for or are granted these roles. This makes it 21 | difficult for community members to know how to apply for a role promotion and 22 | difficult for Working Group leadership to manage Contributor and Approver 23 | candidates. 24 | 25 | In addition, there is no defined process for removing people from Contributor or 26 | Approver roles if they are no longer interested in participating at that level. 27 | 28 | ## Proposal 29 | 30 | ### Promotion to Contributor 31 | 32 | - When a person meets the criteria to be a Contributor as defined in 33 | [ROLES.md](https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md), 34 | they may submit a PR adding themselves to 35 | [contributors.yml](https://github.com/cloudfoundry/community/blob/main/orgs/contributors.yml). 36 | 37 | - Two existing Contributors or Approvers must attest that they meet the criteria 38 | by reviewing the PR. 39 | 40 | - An existing Contributor or Approver may submit the promotion request on behalf of someone else, but they 41 | may not serve as a reviewer. 42 | 43 | - A Working Group Lead from any Working Group will merge or close the PR, based 44 | on the results of the review and their discretion. 45 | 46 | - TOC members may bypass the review process and merge the PR at their 47 | discretion. 48 | 49 | ### Promotion to Approver 50 | 51 | - When a person meets the criteria to be an Approver for a Working Group as defined in 52 | [ROLES.md](https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md), 53 | they may submit a PR to the appropriate Working Group Charter that adds 54 | themselves to the team's yaml definition. 55 | 56 | - Two existing Approvers for that Working Group must attest that they meet the criteria 57 | by reviewing the PR. 58 | 59 | - For Working Groups with fewer than 4 approvers, a single Approver review is 60 | sufficient. 61 | 62 | - An existing Approver may submit the promotion request on behalf of someone else, but they 63 | may not serve as a reviewer. 64 | 65 | - A Working Group Lead for that Working Group will merge or close the PR, based 66 | on the results of the review and their discretion. 67 | 68 | - TOC members may bypass the review process and merge the PR at their 69 | discretion. 70 | 71 | ### Revoking Contributor Role 72 | 73 | - People with the Contributor role may submit a PR to revoke their role by 74 | removing the appropriate entry from 75 | [contributors.yml](https://github.com/cloudfoundry/community/blob/main/orgs/contributors.yml). 76 | 77 | - An existing Contributor or Approver may submit the revocation request on 78 | behalf of someone else, but the person whose role is being revoked must be 79 | given two weeks to refute the revocation. 80 | 81 | - A Working Group Lead from any Working Group will merge or close the PR, at 82 | their discretion and without review. 83 | 84 | - TOC members may merge the PR at their discretion. 85 | 86 | ### Revoking Approver Role 87 | 88 | - People with an Approver role may submit a PR to revoke their role by removing 89 | the appropriate entry from the yaml definition in their Working Group's charter. 90 | 91 | - An existing Approver may submit the revocation request on behalf of someone 92 | else, but the person whose role is being revoked must be given two weeks to 93 | refute the revocation. 94 | 95 | - A Working Group Lead for that Working Group will merge or close the PR, at 96 | their discretion and without review. 97 | 98 | - TOC members may merge the PR at their discretion. 99 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0010-stemcell-cleanup.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Stemcell Cleanup 4 | - Start Date: 2022-06-14 5 | - Author(s): @rkoster 6 | - Status: Accepted 7 | - RFC Pull Request: [community#308](https://github.com/cloudfoundry/community/pull/308) 8 | 9 | 10 | ## Summary 11 | 12 | In an effort to reduce ongoing IaaS spend of the Cloud Foundry Foundation this RFC proposes cleanup schedules for light and heavy stemcells. 13 | 14 | ## Problem 15 | 16 | Currently heavy stemcells (full stemcell images stored in s3/gcs) are stored indefinitly. This is also true for the images backing light stemcells. 17 | This becomes a costly endevour, especially on AWS where we need to keep an EBS snapshot per region per light stemcell. 18 | 19 | It has been estimated that cleaning up old stemcells could save tens of thousands of dollars. 20 | 21 | In addition to published stemcells we also store candiate stemcells which never have been published indefinitly. 22 | These should be safe to cleanup after we are sure we are not going to publish them. 23 | 24 | ## Proposal 25 | 26 | - Clean up stemcells (heavy, light, windows, etc.) older than 3 years. 27 | - Clean up unpublished candidate stemcells after 2 months. 28 | 29 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0011-move-buildpacks-dependencies-to-cff.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Move Buildpack Dependencies Repository to CFF 4 | - Start Date: 2022-05-18 5 | - Author(s): @gerg 6 | - Status: Accepted 7 | - RFC Pull Request: [community#279](https://github.com/cloudfoundry/community/pull/279) 8 | 9 | ## Summary 10 | 11 | Move ownership of the buildpack dependency repositories from VMware to the Cloud 12 | Found Foundation (CFF). 13 | 14 | ## Problem 15 | 16 | As part of staging, Cloud Foundry buildpacks download their dependencies from a 17 | VMware-managed central dependency repository. For example, here is an excerpt 18 | from staging an app using the ruby buildpack: 19 | ``` 20 | -----> Ruby Buildpack version 1.8.53 21 | -----> Supplying Ruby 22 | -----> Installing bundler 2.3.11 23 | Download [https://buildpacks.cloudfoundry.org/dependencies/bundler/bundler_2.3.11_linux_noarch_any-stack_cab63d95.tgz] 24 | -----> Installing ruby 2.7.5 25 | Download [https://buildpacks.cloudfoundry.org/dependencies/ruby/ruby_2.7.5_linux_x64_cflinuxfs3_2c25fe7d.tgz] 26 | -----> Update rubygems from 3.1.6 to 3.3.11 27 | -----> Installing rubygems 3.3.11 28 | Download [https://buildpacks.cloudfoundry.org/dependencies/rubygems/rubygems_3.3.11_linux_noarch_any-stack_a9fa9578.tgz] 29 | -----> Installing dependencies using bundler 2.3.11 30 | Running: bundle install --jobs=4 --retry=4 --local 31 | ``` 32 | 33 | The `*.cloudfoundry.org` DNS Zone is managed by the CFF, so VMware is not able to 34 | renew the TLS certificate for this dependency 35 | repository. This issue came to a head on March 27 2022, when the 36 | `buildpacks.cloudfoundry.org` TLS certificate expired, resulting in widespread 37 | staging failures. Luckily, VMware had access to a `*.cloudfoundry.org` TLS 38 | certificate, which does not expire until February 23 2023. Going forward, VMware 39 | will need to coordinate certificate renewals with the CFF until this problem is 40 | resolved, risking future outages. 41 | 42 | In addition to `buildpacks.cloudfoundry.org`, the Java buildpack is also 43 | dependent on a dependency repository, `java-buildpack.cloudfoundry.org`, with a 44 | certificate expiring in May 2023. Both of these repositories are currently 45 | implemented using AWS CloudFront distributions, backed by AWS S3 buckets. These 46 | AWS resources are controlled by teams within VMware, and are not easily 47 | accessible to Application Runtime Interfaces working group members, including 48 | those who work for VMware. 49 | 50 | Historically, we have not migrated the buildpack dependency repository because: 51 | 1. It it difficult to transfer large S3 buckets between AWS accounts 52 | 1. The storage and network traffic for the dependency repository is expensive, 53 | and VMware has agreed to pay for it 54 | 55 | 56 | ## Proposal 57 | 58 | Move the buildpack dependency repository CloudFront distributions 59 | (`buildpacks.cloudfoundry.org` and`java-buildpack.cloudfoundry.org`) to a 60 | CFF-managed AWS account, but keep the existing S3 blobstore in a VMware-managed 61 | AWS account for the time being. 62 | 63 | **Pros:** 64 | 1. Reduces dependency on single vendor (VMware) for Cloud Foundry operation 65 | 1. Moves control of the buildpack dependency repositories into a CFF working group 66 | 1. Doesn't require significant redesign of existing systems 67 | 1. Less expensive for the CFF than migrating both CloudFront distributions and S3 buckets 68 | 1. Doesn't require migrating S3 buckets between AWS accounts 69 | 70 | **Cons:** 71 | 1. Does not fully remove dependency on single vendor (VMware) for Cloud Foundry 72 | operation, since the S3 buckets will still be under VMware control 73 | 1. Does not address underlying centralization issue with buildpacks 74 | 1. May be too expensive for the CFF to maintain under current funding, depending 75 | on network traffic cost 76 | 1. Using CloudFront and S3 across two AWS accounts may result in some unforeseen 77 | issues 78 | 1. This migration will require some engineering and coordination effort between 79 | the CFF and teams within VMware to ensure a low/no downtime transfer. 80 | 81 | ### Fallback Plans 82 | 83 | - In the event that we are not able to execute on this proposal prior to the 84 | certificates' expirations, the Application Runtime Interfaces 85 | working group will coordinate with the CFF to renew the certificate manually. 86 | - Once this proposal is implemented, the TOC will monitor the cost of maintaining 87 | the CloudFront distributions. In the event that the TOC deems the costs too 88 | high for the CFF to maintain, we will revert back to VMware-managed CloudFront 89 | distributions, ideally under the direct control of VMware members of the 90 | Application Runtime Interfaces working group. 91 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0012-formal-aspiring-approvers-as-reviewers.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Formally track aspiring approvers as reviewers 4 | - Start Date: 2022-07-05 5 | - Author(s): @rkoster, @stephanme 6 | - Status: Accepted 7 | - RFC Pull Request: [community#333](https://github.com/cloudfoundry/community/pull/333) 8 | 9 | 10 | ## Summary 11 | 12 | Extend the working group yaml definitions to optionally include a `reviewers` key per area with a list of contributors who like to become approvers. 13 | The github org automation should use this information to create a github team for the area with `-reviewers` suffix and __read__ permissions. 14 | 15 | This will later allow automatic assignment of PRs to be reviewed, which will help these contributors more easily satisfy the requirements to become approvers. An additional use case might be granting read access to non-public CI pipelines. 16 | 17 | ## Problem 18 | 19 | Due to the way to cloudfoundy github organization is setup, contributors gain no additional access rights within the organization. 20 | This prevents PRs to be assigned to them to be reviewed. 21 | 22 | In addition, the current process for getting people approver status relies a lot on the discipline of contributors to rack up the [needed contribution points](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0006-approver-requirements.md). 23 | Ideally we create an opt-in low resistance path, to help contributors get to approver status quicker. 24 | A lack of enough approvers hinders our ability as a community to review and approve PRs in a timely manner. 25 | Improving the number of approvers should be the top priority of working group leads. 26 | 27 | ## Proposal 28 | 29 | Allow tracking aspiring approvers as `reviewers` per working group area. Create a `*-reviewers` team per area that includes a `reviewers` key with read access to the area's repos. 30 | 31 | This extends [RFC-005 Standardizing Github Teams and Access](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0005-github-teams-and-access.md): 32 | 33 | | Name of Team | Team Membership | Permissions | 34 | |---|---|---| 35 | | wg-[WORKING-GROUP-NAME]-[AREA-NAME]-reviewers | Contributors who want to become approver for an area within a WG | Read access for all repos in the area, so that PRs can be assigned for review | 36 | 37 | `reviewers` are not included in the overall working group team `wg-[WORKING-GROUP-NAME]`. 38 | 39 | Where: 40 | * `WORKING-GROUP-NAME` is the name of the Working Group, converted to kebab case, 41 | * `AREA-NAME` is the name of the area, also converted to kebab case, or a suitable short name that identifies it clearly and uniquely within the Working Group. 42 | 43 | [RFC-008 Role Change Process](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0008-role-change-process.md) gets extended as well: 44 | 45 | ### Promotion to Reviewer 46 | 47 | - When a contributor wishes to get a Reviewer for a Working Group area, 48 | they may submit a PR to the appropriate Working Group Charter that adds 49 | themselves to the team's yaml definition. 50 | 51 | - Two existing Approvers for that Working Group must support the promotion by reviewing the PR. 52 | There are no specific criteria beside being a contributor. 53 | 54 | - For Working Groups with fewer than 4 approvers, a single Approver review is 55 | sufficient. 56 | 57 | - An existing Approver may submit the promotion request on behalf of someone else, but they 58 | may not serve as a reviewer. 59 | 60 | - A Working Group Lead for that Working Group will merge or close the PR, based 61 | on the results of the review and their discretion. 62 | 63 | - TOC members may bypass the review process and merge the PR at their 64 | discretion. 65 | 66 | ### Revoking Reviewer Role 67 | 68 | - People with an Reviewer role may submit a PR to revoke their role by removing the appropriate entry from the yaml definition in their Working Group's charter. 69 | 70 | - An existing Approver may submit the revocation request on behalf of someone else, but the person whose role is being revoked must be given two weeks to refute the revocation. 71 | 72 | - A Working Group Lead for that Working Group will merge or close the PR, at their discretion and without review. 73 | 74 | - TOC members may merge the PR at their discretion. -------------------------------------------------------------------------------- /toc/rfc/rfc-0013-remove-nonstandard-github-teams.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Remove Non-Standard GitHub Teams 4 | - Start Date: 2022-04-28 5 | - Author(s): @gerg 6 | - Status: Accepted 7 | - RFC Pull Request: [community#262](https://github.com/cloudfoundry/community/pull/262) 8 | 9 | 10 | ## Summary 11 | 12 | Remove GitHub teams (and associated access) that are outside of the CFF 13 | governance model. 14 | 15 | ## Problem 16 | 17 | There are currently many GitHub teams in the `cloudfoundry` GitHub organization 18 | that do not correlate with a CFF-recognized entity (working group, TOC, etc). 19 | These teams grant access to CFF-governed repositories, but are not beholden to 20 | the CFF's roles and other processes for governing access. In addition, the 21 | volume of GitHub teams makes it more difficult to manage team access via the 22 | GitHub UI and intermediary tools like 23 | [`orgs.yml`](https://github.com/cloudfoundry/community/blob/main/orgs/orgs.yml). 24 | 25 | Nevertheless, controlling access to Cloud Foundry repositories only by teams defined by CFF technical governance is a substantial change from the previous system of access and team management and in the short term will cause unexpected loss of access to repositories for some contributors and automated development and release processes. 26 | 27 | As per [RFC 0007](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0007-repository-ownership.md), CFF staff also require access to many repositories in the Cloud Foundry GitHub organization that are outside the scope of project technical operation, such as those for CFF websites or the Cloud Foundry Certified Developer examinations. 28 | ## Proposal 29 | 30 | Delete all GitHub teams in the `cloudfoundry` organization that do not conform 31 | to 32 | [rfc-0005-github-teams-and-access](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0005-github-teams-and-access.md) 33 | or another CFF-recognized entity, such as CFF staff members. 34 | 35 | To allow the CF community to function while the Working Groups adjust their scope and membership, the TOC will permit the formation of exceptional teams on a case-by-case basis. These exceptional teams must be identified as such clearly in their names with phrases such as "temporary" and "delete me", and these teams should be related to unofficial teams that were previously deleted. The TOC and Working Groups will review these exceptional teams regularly for deletion, with the goal of removing all exceptional teams by the end of 2022. 36 | 37 | CFF staff may create teams as needed to administer repositories outside the scope of technical project operation. The names for any such teams should clearly indicate their relation to CFF staff responsibilities. 38 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0014-github-teams-and-access.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Standardizing Github Teams and Access 4 | - Start Date: 2022-07-28 5 | - Author(s): @ameowlia, @stephanme 6 | - Status: Accepted 7 | - RFC Pull Request: [community#375](https://github.com/cloudfoundry/community/pull/375) 8 | 9 | 10 | ## Summary 11 | 12 | All working groups SHOULD create GitHub teams using the standardized name 13 | format. 14 | 15 | Supersedes [rfc-0005-github-teams-and-access](https://github.com/cloudfoundry/community/blob/main/toc/rfc/archived/rfc-0005-github-teams-and-access.md) 16 | 17 | ## Problem 18 | 19 | CFF technical governance has changed to be organized around working groups and 20 | new roles like Tech Lead and Approver. Most working groups also have sub-groups. 21 | 22 | We need ways within the community to: 23 | * Provide the team members with proper push access to certain repos, 24 | * Provide a way for others to tag groups of people. 25 | 26 | ## Proposal 27 | 28 | Every working group SHOULD use GitHub teams within the necessary CFF Managed 29 | Github Org to reflect the following groups. The GitHub teams SHOULD be 30 | provisioned automatically from the yaml blocks in the working group charters. 31 | 32 | | Name of Team | Team Membership | Permissions | 33 | |---|---|---| 34 | | toc | Technical Oversight Committee | Admin access to everything | 35 | | wg-leads | Tech and Execution Leads for all WGs | Write access to community repo | 36 | | wg-[WORKING-GROUP-NAME] | All approvers and leads for a WG | None: only for organization and tagging | 37 | | wg-[WORKING-GROUP-NAME]-leads | All leads for a WG | Admin access for all WG repos | 38 | | wg-[WORKING-GROUP-NAME]-bots | Bot accounts for a WG | Write access for all WG repos | 39 | | wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers | Approvers & tech leads for an area within a WG | Write access for all repos in the area | 40 | | wg-[WORKING-GROUP-NAME]-[AREA-NAME]-reviewers | Contributors who want to become approver for an area within a WG | Read access for all repos in the area, so that PRs can be assigned for review | 41 | | wg-[WORKING-GROUP-NAME]-[AREA-NAME]-bots | Bot accounts for an area within a WG | Write access for all repos in the area | 42 | 43 | Where: 44 | * `WORKING-GROUP-NAME` is the name of the Working Group, converted to kebab 45 | case, 46 | * `AREA-NAME` is the name of the area, also converted to kebab case, or a 47 | suitable short name that identifies it clearly and uniquely within the 48 | Working Group. 49 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0015-branch-protection.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Default git branch protection rules 4 | - Start Date: 2022-10-07 5 | - Author(s): AP-Hunt, Benjamintf1, rkoster 6 | - Status: Accepted 7 | - RFC Pull Request: [community#449](https://github.com/cloudfoundry/community/pull/449) 8 | 9 | 10 | ## Summary 11 | 12 | In Q3 2022, the Technical Oversight Committee accepted and implemented [an RFC for the management of GitHub teams and user access](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0014-github-teams-and-access.md). This unintentionally broke the workflow and branch protection rules of some working groups. 13 | 14 | This RFC seeks to address that by defining a baseline of branch protection rules across all repositories under management in the cloudfoundry GitHub org. 15 | 16 | ## Problem 17 | 18 | Prior to the approval and implementation of RFC 0014, some working groups had set up branch protection rules on their repositories to enable things like: 19 | * allowing members of cloudfoundry org without approver status in the working group to push only to non-release-line branches 20 | * allowing approvers in the working group to push to both release-line and non-release-line branches 21 | * allowing release bots to push commits to release-line branches 22 | 23 | When the TOC approved and implemented [RFC 0013](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0013-remove-nonstandard-github-teams.md), any GitHub teams within the cloudfoundry org that were **not** defined in working group charter were removed. This broke branch protection rules because they were now referring to non-existent teams. 24 | 25 | ## Proposal 26 | 27 | The CFF TOC should implement basic branch protection rules for all repositories in an automated manner, and allow working groups to extend them as they see fit. This can be achieved, technically, with [the `branchprotector` tool from `prow` toolset](https://github.com/kubernetes/test-infra/blob/master/prow/cmd/branchprotector/README.md). 28 | 29 | We propose that protection be applied to all branches matching either the default branch or the expression `v[0-9]*`. 30 | 31 | On protected branches, we propose the following rules: 32 | * only the bots for the Working Group owning the repository and any areas in the Working Group contributing to the repository may push directly to the branch 33 | * human contributors must make contributions through a regular pull request workflow. 34 | 35 | With respect to the approval of pull requests, we propose that the number of approvals required will depend on the number of people in the approver role of a working group: 36 | * 0 approvals will be required when a working group has 3 or fewer people in the approver rule 37 | * 1 approval will be required when a working group has 4 or more people in the approver role. 38 | 39 | The automation should allow to override the standard branch protection per respository using a configuration file maintained in this community repository. This allows working group leads e.g. to reduce the number of required approvals if several approvers are temporarily not available. 40 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0021-toc-stand-in-for-wg-lead.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: TOC Can Stand in for Working Group Leads 4 | - Start Date: 2023-08-28 5 | - Author(s): Amelia Downs 6 | - Status: Accepted 7 | - RFC Pull Request: [community#676](https://github.com/cloudfoundry/community/pull/676) 8 | 9 | 10 | ## Summary 11 | 12 | Working Group Leads are in charge of approving and merging PRs for their 13 | Working Group. When the TOC decideds it is necessary, the TOC MAY make decisions in their place. 14 | 15 | ## Problem 16 | 17 | Sometimes Working Group Leads go on vacation or get sick and are not available 18 | to take actions for their working group. This can cause work in the working group to be blocked until 19 | the Working Group Lead returns. 20 | 21 | ## Proposal 22 | 23 | When the TOC decides it is necessary, the TOC MAY make decisions in their stead. This 24 | includes approving and merging PRs for their Working Group. All actions MUST 25 | have the approval of a majority of the TOC members. 26 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0022-deprecate-metrics-agent.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Deprecated Metrics Agent 4 | - Start Date: 2023-09-12 5 | - Author(s): @mkocher @rroberts2222 6 | - Status: Accepted 7 | - RFC Pull Request: [community#682](https://github.com/cloudfoundry/community/pull/682) 8 | 9 | ## Summary 10 | 11 | Metrics Agent was added as a way to egress metrics by serving a prometheus 12 | endpoint of metrics sent to the Forwarder Agent. We don't know of any users, 13 | and the functionality can now be accomplished using the prometheus exporter of 14 | OpenTelemetry Collector. 15 | 16 | ## Problem 17 | 18 | We are maintaining code that no one is using and has a viable alternative. 19 | 20 | ## Proposal 21 | 22 | - Today - Mark [metrics-discovery-release](https://github.com/cloudfoundry/metrics-discovery-release) repo as deprecated 23 | - In One Month 24 | * Accept a PR to move metrics-agent to an ops file in CF-deployment, if a community member needs metrics-agent and would like a ops file 25 | * Remove metrics-agent from cf-deployment 26 | * Remove references to metrics-agent from documentation 27 | - In Three Months - Stop cutting new releases of metrics-agent 28 | 29 | 30 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0024-promoting-or-revoking-wg-leads.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Promoting and Revoking Working Group Leads 4 | - Start Date: 2023-10-11 5 | - Author(s): @ameowlia 6 | - Status: Accepted 7 | - RFC Pull Request: [community#704](https://github.com/cloudfoundry/community/pull/704) 8 | 9 | ## Summary 10 | 11 | Define the process for promoting or removing Tech Leads and Execution Leads for 12 | Working Groups. 13 | 14 | ## Problem 15 | 16 | Currently there is no defined process for how to promote or remove Tech Leads 17 | or Execution Leads for Working Groups. This process should be defined. 18 | 19 | ## Proposal 20 | In this proposal the word "Lead" encompasses both the "Tech Lead" and 21 | "Execution Lead" roles. As currently stated in the 22 | [ROLES.md](https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md) 23 | document, both Lead roles are sponsored by the TOC. 24 | 25 | ### Promotion to Lead 26 | * If a person meets the criteria to be a Lead as defined in 27 | [ROLES.md](https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md), 28 | they MAY submit a PR adding themselves to the contributors.yml as a Lead. 29 | 30 | * The TOC will start a one week final comment period on the PR to collect 31 | approvals from the required parties. 32 | 33 | * The TOC MUST approve the PR before it can be merged. 34 | 35 | * At least one current Lead for the affected Working Group SHOULD approve the PR 36 | before it can be merged. 37 | 38 | * Any current approvers for the affected Working Group MAY 'vote' by commenting 39 | "+1" or "-1" on the PR. 75% or more of the votes from current Working Group 40 | approvers MUST vote "+1" for the promotion in order for the PR to be merged. 41 | 42 | ### Revoking Lead Role 43 | * A Lead MAY revoke their own role by submiting and merging their own PR to 44 | remove themselves from the `contributors.yml` file for their Working Group. 45 | 46 | * Any Approver in the Working Group or a TOC member MAY submit a PR revoke the 47 | Lead role from the current holder. The person whose role is being revoked 48 | MUST be given two weeks to refute the revocation. The TOC MUST make the final 49 | decision to revoke the Lead role. 50 | 51 | 52 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0025-define-criteria-and-removal-process-for-inactive-members.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Define Criteria and Process to Remove Inactive Cloud Foundry Github Members 4 | - Start Date: 2023-10-25 5 | - Author(s): @beyhan 6 | - Status: Accepted 7 | - RFC Pull Request: [community#707](https://github.com/cloudfoundry/community/pull/707) 8 | 9 | ## Summary 10 | 11 | Define criteria for the Cloud Foundry Github organization which can be used to identify inactive members. Additionally, define a process how to remove the inactive members. 12 | 13 | It is out of scope for this RFC to deal with users having roles in any working group. It is the responsibility of the working group leads to keep the approvers and reviewers up to date. 14 | 15 | ## Problem 16 | 17 | Currently, there are no criteria to identify inactive members in the Cloud Foundry Github organization. Therefore we have many members in the Cloud Foundry organization, who are not actively contributing anymore and not part of any working group. This has many downsides for the foundation like: 18 | * We don't know how many active members we have 19 | * A potential change of the Github plan which costs depends on the number of Github organization members will generate higher costs 20 | * Security risk because some of the inactive members could have access to resources belonging the Cloud Foundry Github organization 21 | 22 | ## Proposal 23 | 24 | In this proposal the word "contributions" to the repositories of the Cloud Foundry Github organization includes following activities: 25 | * Code contributions 26 | * Creation, discussion or review of pull-requests 27 | * Creation or discussion of issues 28 | 29 | ### Criteria for Inactive Members 30 | 31 | The period to analyze should be the last 12 months and following criteria should be used to identify inactive users: 32 | * The user is not listed in any working group as reviewer or approver 33 | * There are no contributions to the Cloud Foundry Github organization repositories 34 | 35 | ### Remove the membership to the Cloud Foundry Github Organization 36 | 37 | If the inactivity criteria are fulfilled for a member they should be removed from the Cloud Foundry Github organization. Any automation, approver or TOC member may submit a PR to remove the member from the Cloud Foundry Github organization. The person whose membership is being removed must be given two weeks to refute the removal. The working group lead to which the member belongs or TOC in case the member doesn't belong to any working group must make the final decision to remove the membership by merging the PR. 38 | 39 | #### Implementation 40 | 41 | This process should be fully automated until a pull-request for the removal is created. It should do following: 42 | 1. Find the Github users listed in [contributors.yml](https://github.com/cloudfoundry/community/blob/main/orgs/contributors.yml) without any working group role 43 | 2. Find the inactive Github users from 1). We will implement this by ourself or use tools like [inactive-users-action](https://github.com/peter-murray/inactive-users-action/tree/main). 44 | 3. Create a pull-request to remove the user from the Cloud Foundry Github organization 45 | 46 | #### Initial cleanup 47 | As described in the problem section of this RFC there are many inactive members in the Cloud Foundry Github organization. Therefore, for the initial cleanup we should have an exception to create a bulk PR with all inactive members. Having PRs for every user will be very high effort because there are several hundreds of inactive users currently. 48 | 49 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0026-noble-os.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Support Noble Numbat (24.04) as the CF Linux 4 | - Start Date: 2024-03-01 5 | - Author: @beyhan 6 | - Contributing Authors: @rkoster, @jochenehret 7 | - Status: Accepted 8 | - RFC Pull Request: [community#789](https://github.com/cloudfoundry/community/pull/789) 9 | 10 | 11 | ## Summary 12 | 13 | The CFF community should add support for Noble Numbat (24.04) as CF Operating System. 14 | 15 | ## Problem 16 | 17 | The current Operating System for CF is Jammy Jellyfish (22.04), which has the end of standard support planned for 2027.06. The next planned long term support (LTS) releases for Ubuntu are Noble Numbat (24.04) and most probably one in 26.04 because Ubuntu has a two year lifecycle for LTS releases. If we skip the Noble Numbat support we will have approximately one year to implement the support and adoption for the next LTS release. In the past the CFF community decided to [skip Ubuntu Focal](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0001-jammy-os.md) and move directly to Jammy Jellyfish (22.04) LTS, which turned out to be quite challenging due to: 18 | - The short time available for the overall execution 19 | - The implementation effort is unknown upfront because it depends on the changes introduced with the new OS version 20 | - Almost impossible to introduce backwards incompatible changes like removal of unneeded libraries because of the short time available for validation and adoption 21 | 22 | 23 | ## Proposal 24 | 25 | The CFF community should not skip the Noble Numbat (24.04) release. The CFF community should start work on publishing a stemcell line based on Noble Numbat starting in March or April of 2024. This means that until the end of planned support for Jammy two stemcell lines (Jammy and Noble) will be supported, which can affect the tests and validations of the CF components. The CF components should take the responsibility to decide what kind of tests and validation makes sense for the two stemcell lines. The Slack channel [bosh-noble](https://cloudfoundry.slack.com/archives/C06HTDT78N9) should be used for communication around this effort. 26 | 27 | ## Workstreams 28 | 29 | The major milestones have been documented below in more details per working group. 30 | 31 | ### Foundational Infrastructure WG 32 | 33 | The Foundational Infrastructure Working Group is responsible for making new stemcells. As soon as Noble Numbat (24.04) packages from Ubuntu are available the WG can start working on the new stemcell. The effort in the FI WG includes following rough list of steps: 34 | - Extend [bosh-linux-stemcell-builder](https://github.com/cloudfoundry/bosh-linux-stemcell-builder) for Noble Numbat 35 | - Noble Numbat stemcell is produce by CI 36 | - BOSH agent works 37 | - BOSH Director works 38 | - BOSH acceptance tests run successfully 39 | - Make a 0.x beta version of the stemcell available for CFF community validation 40 | - After successful validation in the community publish 1.x GA stemcell version on [bosh.io](http://bosh.io) 41 | 42 | 43 | The end of planned support for Jammy Jellyfish (22.04) is 06.2027. That is why for Noble Numbat we can take some time to look into topics from the [wish list](https://github.com/cloudfoundry/bosh-linux-stemcell-builder/milestone/1). The RFC suggests targeting a beta stemcell available for the end of Q3 2024, which could be used by the App Runtime Deployment for validation. The FI WG will implement the same release validation for Noble like the one existing currently for Jammy. 44 | 45 | ### App Runtime Deployments WG 46 | 47 | Once initial confidence has been gained by validating the Noble Numbat stemcell against the BOSH director it is time to validate against cf-deployment. A simular validation like the one existing for Jammy stemcell should be set up for Noble which will use the beta 0.x version of the stemcell provided by the FI WG. GCP will be used as the initial validation environment but if required validation on AWS could be added. Issues discovered by this validation should be distributed to the related CF components. It is their responsibility to address them. If CF components want to have faster feedback on Noble Numbat issues they can add their own validation. When the cf-deployment validation of Noble is successful the FI WG will release the 1.x GA version of the Noble Numbat stemcell. The Noble Numbat validation in cf-deployment will be kept also after the 1.x GA release. At this point cf-deployment will also provide an `ops-file`, which can be used by CF operators to switch to Noble Numbat. Additionally, cf-deployment should decide to make the Noble stemcell the default one well before the EOF for Jammy so that CF operators have enough time to migration from Jammy to Noble. -------------------------------------------------------------------------------- /toc/rfc/rfc-0029-ssh-over-ws/cf-ssh-over-websocket.drawio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/community/3e9889fc3835b5457b325656c4e59c7d196d3162/toc/rfc/rfc-0029-ssh-over-ws/cf-ssh-over-websocket.drawio.png -------------------------------------------------------------------------------- /toc/rfc/rfc-0031-system-cnb.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: System Cloud Native Buildpacks 4 | - Start Date: 30.04.2024 5 | - Author(s): @c0d1ngm0nk3y, @pbusko, @nicolasbender, @modulo11 6 | - Status: Accepted 7 | - RFC Pull Request: [community#830](https://github.com/cloudfoundry/community/pull/830) 8 | - Predecessor: https://github.com/cloudfoundry/community/pull/796 9 | 10 | ## Summary 11 | 12 | This RFC proposes extending the Cloud Foundry functionality to introduce and support system Cloud Native Buildpacks (CNBs). It will allow users to initiate the `cf push --lifecycle cnb` command without providing an explicit list of buildpacks, relying instead on the list of system buildpacks and the built-in auto-detection mechanism. 13 | 14 | ## Problem 15 | 16 | Despite the recent integration of CNBs in the Cloud Foundry platform, the feature still has limitations that could hinder user experience and efficiency. Currently, only custom buildpacks are supported. Users have to manually provide a list of buildpacks (at least one) for their application to run with the `cnb` lifecycle type. 17 | 18 | ## Proposal 19 | 20 | - Make it possible to configure the default application lifecycle with the following options: `buildpack` or `cnb`. The value of this setting will be further reffered to as the *default lifecycle*. 21 | - Introduce a new `lifecycle` column to the [buildpack object](https://v3-apidocs.cloudfoundry.org/index.html#the-buildpack-object) with ENUM values `cnb` or `buildpack`. If the value is not provided, the default lifecycle MUST be used. 22 | - Add new parameter `lifecycle` to the [`POST /v3/buildpacks`](https://v3-apidocs.cloudfoundry.org/index.html#create-a-buildpack) API endpoint. If the value is not provided, the default lifecycle MUST be used. 23 | - Cloud Native Buildpacks MUST be stored in format of a gzipped OCI tarball. The layout of the tarball is outlined in the [OCI Image Layout Specification](https://github.com/opencontainers/image-spec/blob/main/image-layout.md) 24 | - Add support for gzipped OCI tarballs when uploading a buildpacks using [`POST /v3/buildpacks/:guid/upload`](https://v3-apidocs.cloudfoundry.org/index.html#upload-buildpack-bits) API endpoint 25 | - `cf push` command without specifying an explicit list of buildpacks MUST perform auto-detection using the system buildpacks based on their priority. The type of the buildpacks and the lifecycle are based on the default lifecycle. 26 | - `cf push --lifecycle buildpack|cnb` command without an explicit list of buildpacks MUST perform auto-detection using the selected lifecycle, based on their priority. 27 | - `cf push --lifecycle buildpack|cnb -b ` command MUST use only the selected system buildpacks with the lifecycle specified by the `--lifecycle` flag and fail the staging process if the buildpack's detection fails. 28 | - `cf push -b ` command MUST use only the selected system buildpacks, using the lifecycle specified by the default lifecycle. 29 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0032-cfapiv2-eol.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: CF API v2 End of Life 4 | - Start Date: 2024-08-08 5 | - Author(s): stephanme 6 | - Status: Accepted 7 | - RFC Pull Request: [community#941](https://github.com/cloudfoundry/community/pull/941) 8 | 9 | 10 | ## Summary 11 | 12 | CF API v2 is deprecated since at least 2021 but there is no End of Life date communicated (see [ccng #2725](https://github.com/cloudfoundry/cloud_controller_ng/discussions/2725)). 13 | 14 | This RFC shall define a plan to disable and finally remove CF API v2 from CAPI and cf-deployment. 15 | 16 | ## Problem 17 | 18 | There are several issues and efforts with keeping the deprecated CF API v2 as part of CAPI and cf-deployment: 19 | 20 | - Maintenance effort in CAPI and CF API client libraries 21 | - CF API v2 uses a different Ruby web framework than v3 22 | - Shipping an API that is not well tested anymore: CATS don’t test CF API v2 23 | - Performance problems especially in large foundations: metrics show that v2 requests take between 3 to 5 times as long as v3 requests on average 24 | - Larger cloud controller database schema refactorings/improvements are not possible or at least difficult because the same DB schema has to serve v2 and v3. This blocks performance improvements in CF API v3. 25 | - Example: [ccng decision 0007-implementing-v3-roles.md](https://github.com/cloudfoundry/cloud_controller_ng/blob/main/decisions/0007-implementing-v3-roles.md) 26 | - Areas where schema changes could lead to performance improvements: roles, service plan visibilities 27 | - More fine grained org and space roles, a recurring user request, would benefit from a DB schema migration away from the current one table per role design. Blocked as well by CF API v2. 28 | 29 | ## Proposal 30 | 31 | Since CF API v2 removal is a fundamental breaking change, the removal is divided into 3 phases of about 1 year each with checkpoints in between that require TOC approval. 32 | If the TOC does not approve moving to the next phase, the TOC will decide a number of months to extend the current phase. Subsequent phases and the EoL date will be updated accordingly. The TOC will then re-convene after that period to again evaluate if it is appropriate to move to the next phase. 33 | 34 | **Phase 1** (starts after accepting this RFC) 35 | - Announce an End of Life date for CF API v2 (~ mid/end 2026). 36 | - Engineering work so that all cf-deployment components are built/tested/released with v2 turned off 37 | - Turn off CF API v2 by default in cf-deployment (set CAPI property [cc.temporary_enable_v2](https://bosh.io/jobs/cloud_controller_ng?source=github.com/cloudfoundry/capi-release&version=1.185.0#p%3dcc.temporary_enable_v2) to false). Operators may still re-enable v2. 38 | 39 | **Checkpoint 1** 40 | - [cf-deployment v47.0.0](https://github.com/cloudfoundry/cf-deployment/releases/tag/v47.0.0) ships with disabled CF API v2. It can be re-enabled by operators using [enable-v2-api.yml](https://github.com/cloudfoundry/cf-deployment/blob/main/operations/enable-v2-api.yml). 41 | - TOC approval documented in PR [community#1058](https://github.com/cloudfoundry/community/pull/1058) 42 | 43 | **Phase 2** (after Checkpoint 1, ~mid/end 2025) 44 | - Engineering work so that all CFF-controlled clients use v3 by default 45 | - Window for 3rd-party clients to complete migration to v3 46 | 47 | **Checkpoint 2** 48 | - TOC approval 49 | 50 | **Phase 3** (after Checkpoint 2, ~mid/end 2026) 51 | - Turn CF API v2 permanently off for CAPI/cf-deployment. 52 | - Engineering work to remove CF API v2 from CAPI. 53 | 54 | ### Impact and Consequences 55 | 56 | - CF API client libraries like [cf-java-client](https://github.com/cloudfoundry/cf-java-client), [cf-goclient](https://github.com/cloudfoundry/go-cfclient) and [cf_exporter](https://github.com/cloudfoundry/cf_exporter) should plan for closing gaps in CF API v3 support and for removing their CF API v2 implementation. 57 | - CF CLI v6 and v7 still use CF API v2 and will stop working against foundations with disabled CF API v2. CF CLI v8 doesn’t use CF API v2 anymore (exception: CLI plugins, see next point). 58 | - Most CF CLI plugins rely on CF API v2. A new CF CLI plugin interface should be defined (out of scope of this RFC). However, it is possible to implement a CLI plugin without using CF API v2. 59 | - Cloud Foundry users and operators may use tooling and CI/CD pipelines which still rely on CF API v2 and therefore have migration efforts. 60 | 61 | CF API v2 specific rate limiting and the feature flag to disable CF API v2 completely is already implemented in CAPI. 62 | The [CF API v3 Upgrade Guide](https://v3-apidocs.cloudfoundry.org/index.html#upgrade-guide) helps authors of CF api clients to migrate from v2 to v3. 63 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0033-user-creation-by-org-managers.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: User Creation by Org Managers 4 | - Start Date: 2024-08-13 5 | - Author(s): stephanme 6 | - Status: Accepted 7 | - RFC Pull Request: [community#946](https://github.com/cloudfoundry/community/pull/946) 8 | 9 | 10 | ## Summary 11 | 12 | Allow Org Managers (and CF Admins) to create users in UAA in order to improve the onboarding procedure for larger developer groups into multi-tenant Cloud Foundry foundations. The users are created by the Cloud Controller on behalf of the Org Manager. 13 | 14 | ## Problem 15 | 16 | In order to assign CF roles to users, the users must be available in the UAA. As of today, the user is created in UAA explicitly by an administrator (origin=uaa) or implicitly when the user authenticates the first time via CF UAA for setups where an external identity provider is used (other origins). 17 | 18 | This is an issue for customers that want to onboard larger developer groups into multi-tenant Cloud Foundry foundations. All developers would have to log-in into the foundation before CF roles can be assigned - which is impractical. Customers should be able to automate the complete onboarding e.g. using CF CLI or other CF API clients like a CF terraform provider. 19 | 20 | ## Proposal 21 | 22 | The proposal is to grant Org Managers the right to assign CF roles to users which are not yet known in UAA. The users are created in UAA either explicitly via an enhanced `POST /v3/users` call or implicitly when an Org Manager assigns an organization role using `POST /v3/roles`. 23 | 24 | The functionality SHALL be gated by a deployment manifest configuration flag and SHALL be disabled by default. 25 | 26 | ## Required Changes by Component 27 | 28 | ### Cloud Controller 29 | 30 | #### CAPI Release 31 | 32 | Introduce a configuration flag `cc.allow_user_creation_by_org_manager` which is disabled by default. 33 | 34 | Add configuration for an UAA client that is used for creating the users in UAA on behalf of CAPI, e.g. `uaa.clients.cloud_controller_shadow_user_creation`. The UAA client is required when `cc.allow_user_creation_by_org_manager` is enabled, otherwise optional. 35 | 36 | #### POST /v3/users 37 | 38 | Enhance the [POST /v3/users](https://v3-apidocs.cloudfoundry.org/version/3.172.0/index.html#create-a-user) endpoint by the parameters `username` and `origin`. `guid` and `username` parameters are exclusive. 39 | The existing user creation by `guid` SHALL NOT be changed. 40 | 41 | Required Parameters for Create User by Name 42 | |Name|Type|Description| 43 | |---|---|---| 44 | |username|string|The username as (to be) registered in UAA.| 45 | |origin|string|The origin / identity provider for the user. `origin=uaa` is not allowed as it requires a password. | 46 | 47 | 48 | Permitted roles for Create User by Name 49 | - Admin 50 | - OrgManager (if configuration flag `cc.allow_user_creation_by_org_manager` is enabled) 51 | 52 | CAPI will call the [POST /Users](https://docs.cloudfoundry.org/api/uaa/version/77.14.0/index.html#create-2) endpoint of the UAA using a CAPI owned UAA client with scope `scim.write` or `uaa.admin` for creating the user if it doesn't exist yet in UAA. The user is then registered in the Cloud Controller database under the user guid returned by UAA. 53 | 54 | #### POST /v3/roles 55 | 56 | If a role is created by user name and origin (requires feature flag `set_roles_by_username` to be enabled) and the configuration flag `cc.allow_user_creation_by_org_manager` is enabled, the user with the provided name and origin SHALL be created in CF UAA if the users doesn't exist yet in UAA. 57 | In other words: Role assignment shall succeed even if the user is still unknown to CF UAA. The user is created implicitly similar to `POST /v3/users` by username/origin described above. 58 | 59 | ### UAA 60 | 61 | No changes required. 62 | 63 | ### cf-deployment 64 | 65 | Add an [ops file](https://github.com/cloudfoundry/cf-deployment/blob/main/README.md#ops-files) to enable user creation as Org Manager, i.e. the ops file enables `cc.allow_user_creation_by_org_manager` and provisions the UAA client `cloud_controller_shadow_user_creation` with the required scopes. 66 | 67 | ## Possible Future Work 68 | 69 | Enhance CF CLI to allow user creation as Org Manager if configuration flag `cc.allow_user_creation_by_org_manager` is enabled. 70 | 71 | Possible options are: 72 | - enhance `cf create-user USERNAME [--origin ORIGIN]` (user creation without specifying a password) to try the CF API `POST /v3/users` before calling CF UAA directly so that Org Managers can create users if configuration flag `cc.allow_user_creation_by_org_manager` is enabled 73 | - add a new command `cf create-shadow-user USERNAME [--origin ORIGIN]` that uses CF API `POST /v3/users` instead of calling CF UAA directly 74 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0036-multiple-github-orgs.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Managing Multiple Github Orgs 4 | - Start Date: 2025-01-21 5 | - Author(s): @ameowlia, @rkoster 6 | - Status: Accepted 7 | - RFC Pull Request: [community#1050](https://github.com/cloudfoundry/community/pull/1050) 8 | 9 | ## Summary 10 | 11 | CFF community documentation and automation MUST be updated to be able to handle multiple 12 | Github Orgs. 13 | 14 | ## Problem 15 | 16 | Currently the documentation in the CFF community repo is written as if there is 17 | only one Github Organization: cloudfoundry. However, there are currently two 18 | Github Organizations that the CFF TOC oversees: cloudfoundry and paketo. In the 19 | near future, we plan to add a third Github Organization: concourse. 20 | 21 | We MUST update our documentation to reflect how we want to handle multiple Github organizations. 22 | 23 | ## Proposal 24 | 25 | ### New Definitions 26 | * *CFF Github Orgs* - This includes ALL Github Organizations that the CFF TOC 27 | oversees. This currently includes: cloudfoundry, concourse and paketo. 28 | 29 | * *CFF Managed Github Orgs* - This includes all Github organizations that are 30 | managed via the CFF TOC automation. This currently only includes 31 | cloudfoundry. 32 | 33 | ### Working Groups are per CFF Github Org 34 | Working Groups MUST only contain repos from one CFF Github Org. The org MUST 35 | be defined in the working group yaml. 36 | 37 | ### Rename `org` dir to `orgs` 38 | Currently the directory 39 | [org](https://github.com/cloudfoundry/community/tree/main/org) contains yaml 40 | definitions for the repos and contributors to the cloudfoundry Github org. It 41 | also contains the CFF TOC org management automation scripts. 42 | 43 | This SHOULD be the place where yaml definitions for all CFF Managed Github orgs 44 | are stored. To reflect this, the name of the directory SHOULD be renamed to `orgs`. 45 | 46 | ### Update `contributors.yml` to handle multiple Github Organizations 47 | Currently the 48 | [`contributors.yml`](https://github.com/cloudfoundry/community/blob/0caf07e9d93732b40091cdf7c7c616aa18ec07d2/org/contributors.yml) 49 | file has a list of contributors to the cloudfoundry Github Organization. This 50 | file SHOULD be updated to be able to handle contributors for each CFF Managed 51 | Github Org. Each CFF Managed Github Org MUST have its own list of contributors. 52 | 53 | ### Rename `cloudfoundry.yml` to `orgs.yml` 54 | Currently 55 | [cloudfoundry.yml](https://github.com/cloudfoundry/community/blob/8c7298337a8515d7dfae058b3bd1f88ad0eeaf95/org/cloudfoundry.yml) 56 | contains yaml defining all of the repos in the cloudfoundry Github org. It 57 | already has a top level [`orgs` 58 | key](https://github.com/cloudfoundry/community/blob/8c7298337a8515d7dfae058b3bd1f88ad0eeaf95/org/cloudfoundry.yml#L2). 59 | 60 | All of the repos for all of CFF Managed Github Orgs SHOULD be in one place, and 61 | the file `cloudfoundry.yml` SHOULD be the place for that. To reflect that this 62 | file will contain information about multiple CFF Managed Github Orgs it SHOULD 63 | be renamed `orgs.yml`. 64 | 65 | ### Update other docs to match 66 | All other files that contain references to the cloudfoundry Github org as if it 67 | is the only Github org MUST be updated. 68 | 69 | This includes, but is not limited to the following files: 70 | * https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0002-github-members.md 71 | * https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0007-repository-ownership.md 72 | * https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0014-github-teams-and-access.md 73 | * https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md 74 | 75 | ### Update automation 76 | The Github automation maintained by the TOC MUST be updated to work for multiple orgs. 77 | -------------------------------------------------------------------------------- /toc/rfc/rfc-0039-noble-based-cflinuxfs5.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: Introduce cflinuxfs5 Stack Based on Ubuntu Noble (24.04) 4 | - Start Date: 2025-04-07 5 | - Author(s): @vpetrinski @plamen-bardarov 6 | - Status: Accepted 7 | - RFC Pull Request: [community#1112](https://github.com/cloudfoundry/community/pull/1112) 8 | 9 | ## Summary 10 | 11 | Introducing a new stack called `cflinuxfs5`, which is based on Ubuntu 24.04 LTS (Noble Numbat) to provide an up-to-date root filesystem for application workloads. It will be added alongside the current `cflinuxfs4` (Jammy-based) stack. Additionally, new flavours of the buildpacks will be created which will support the new `cflinuxfs5` stack. 12 | 13 | ## Problem 14 | 15 | The current `cflinuxfs4` stack is based on Ubuntu 22.04 LTS (Jammy). Support ends in 2027 16 | With the release of Ubuntu 24.04 LTS (Noble), newer language runtimes, system libraries, and security updates will increasingly depend on a newer base OS. 17 | `cflinuxfs4` does not provide forward compatibility with these updates, and long-term support planning requires us to begin adopting Noble. 18 | 19 | ## Proposal 20 | 21 | ### Produce a new `cflinuxfs5` stack based on Ubuntu Noble. 22 | It will be introduced as a parallel stack. `cflinuxfs5` will be validated against supported buildpacks and application workloads. 23 | The goal is to support both cflinuxfs4 and cflinuxfs5 until the end-of-life (EOL) for Jammy(cflinuxfs4). 24 | 25 | It will be based on Ubuntu 24.04 LTS (Noble) and follow the same structure, tooling, and release process as the existing `cflinuxfs4` stack process. The production of `cflinuxfs5` belongs to the App Runtime Interfaces Working Group. 26 | 27 | ### Create new buildpack versions that are compatible with `cflinuxfs5` 28 | The creation of a new set of buildpacks that are compatible with `cflinuxfs5`. Each buildpack will be tested against the new `cflinuxfs5` rootfs and updated as needed. 29 | Buildpacks are expected to support both `cflinuxfs4` and `cflinuxfs5` during the transition. 30 | Any buildpack-specific incompatibilities with Ubuntu Noble need to be tracked and patched incrementally. 31 | 32 | ## Workstream 33 | ### App Runtime Interfaces WG 34 | The ARI WG will provide the new `cflinuxfs5` stack and the corresponding buildpacks supporting the new stack. 35 | 36 | ### App Runtime Deployments WG 37 | The ARD WG will integrate the cflinuxfs5 stack into the cf-deployment project and also validate the new stack. The steps will be similar to the cflinuxfs4 adoption (see cloudfoundry/cf-deployment#989): 38 | 39 | - Integrate cflinuxfs5-release into the "update-releases" pipeline to enable automatic version updates 40 | - Provide an experimental ops file to integrate cflinuxfs5 and the cflinuxfs5 buildpacks (as available) 41 | - Run CATs against a cflinuxfs5-enabled cf-deployment 42 | - Promote experimental ops file (or integrate directly into cf-deployment.yml) 43 | - Make cflinuxfs5 the default stack (-> major cf-d release) 44 | - The deprecation and removal of cflinuxfs4 will happen at a later time as that stack is being supported for now. 45 | 46 | #### Supported Stemcell Versions for the Stacks 47 | 48 | | Stack | CFLinux Base OS | Supported Stemcells | 49 | |-------------|---------------------|------------------------------| 50 | | cflinuxfs5 | Ubuntu Noble 24.04 | Noble and Jammy (until EOL) | 51 | | cflinuxfs4 | Ubuntu Jammy 22.04 | Noble and Jammy (until EOL) | 52 | -------------------------------------------------------------------------------- /toc/rfc/rfc-template.md: -------------------------------------------------------------------------------- 1 | # Meta 2 | [meta]: #meta 3 | - Name: (fill in the feature name: My Feature) 4 | - Start Date: (fill in today's date: YYYY-MM-DD) 5 | - Author(s): (GitHub usernames) 6 | - Status: Draft 7 | - RFC Pull Request: (fill in with PR link after you submit it) 8 | 9 | 10 | ## Summary 11 | 12 | An abstract, tl;dr or executive summary of your RFC. 13 | 14 | ## Problem 15 | 16 | Describe the problem your RFC is trying to solve. 17 | 18 | ## Proposal 19 | 20 | Describe your proposal, with a focus on clarity of meaning. You MAY use [RFC2119-style](https://www.ietf.org/rfc/rfc2119.txt) MUST, SHOULD and MAY language to help clarify your intentions. 21 | 22 | -------------------------------------------------------------------------------- /toc/working-groups/app-runtime-deployments.md: -------------------------------------------------------------------------------- 1 | # App Runtime Deployments: Working Group Charter 2 | 3 | ## Mission 4 | 5 | Provide reference deployments of the CF App Runtime to CF community end users, CF community contributors, and CF commercial vendors. 6 | 7 | 8 | ## Goals 9 | 10 | - Community end users can install, evaluate, and operate the CF App Runtime on their preferred infrastructure targets. 11 | - Community end users can understand clear limits of operational scope for reference deployments. 12 | - Community contributors can integrate their component changes into the appropriate reference deployments and verify correct behavior for both new and existing CF App Runtime functionality. 13 | - Vendors and service providers can base their own commercial distributions and offerings of the CF App Runtime on a common starting point for the applicable infrastructure. 14 | 15 | 16 | ## Scope 17 | 18 | - Package and release reference CF App Runtime deployments for different platforms, such as BOSH and, maybe in future, Kubernetes. 19 | - Maintain public roadmaps for each reference deployment. 20 | - Collaborate with other Working Groups to ensure that App Runtime components are integrated regularly into the community deployments. 21 | - Provide the community with tooling and reference pipelines needed to build and release the CF reference deployments. 22 | - Provide the community with test suites to assess functionality and behavioral compatibility of a CF deployment. Collaborate with other Working Groups on the test suites. 23 | - Publicly operate the tooling and reference pipelines to build and release CF reference deployments regularly. 24 | - Provide sensible defaults and sufficient configurability in the reference deployments for the needs of the community, contributors, and commercializing vendors while maintaining reasonable scope for the working group operation. 25 | - Ensure upgrade pathways for reference deployments, with disruptive changes communicated clearly. 26 | 27 | 28 | ## Non-Goals 29 | 30 | - Provide significant extensions or other major projects in the CF App Runtime reference deployments, such as managed services or extension clients. 31 | 32 | ## Roles & Technical Assets 33 | Existing CF App Runtime deployments, namely cf-deployment. 34 | 35 | ```yaml 36 | name: App Runtime Deployments 37 | execution_leads: 38 | - name: Jochen Ehret 39 | github: jochenehret 40 | technical_leads: 41 | - name: Jochen Ehret 42 | github: jochenehret 43 | bots: 44 | - name: ard-wg-gitbot 45 | github: ard-wg-gitbot 46 | areas: 47 | - name: CF Deployment 48 | reviewers: 49 | - github: oliver-heinrich 50 | name: Oliver Heinrich 51 | approvers: 52 | - github: davewalter 53 | name: Dave Walter 54 | - github: ctlong 55 | name: Carson Long 56 | - github: philippthun 57 | name: Philipp Thun 58 | - github: johha 59 | name: Johannes Haass 60 | - github: svkrieger 61 | name: Sven Krieger 62 | - github: iaftab-alam 63 | name: Aftab Alam 64 | - github: dimivel 65 | name: Dimitar Velinov 66 | repositories: 67 | - cloudfoundry/app-runtime-deployments-infrastructure 68 | - cloudfoundry/cf-acceptance-tests 69 | - cloudfoundry/cf-deployment 70 | - cloudfoundry/cf-deployment-concourse-tasks 71 | - cloudfoundry/cf-relint-ci-semver 72 | - cloudfoundry/cf-smoke-tests 73 | - cloudfoundry/cf-smoke-tests-release 74 | - cloudfoundry/cf-test-helpers 75 | - cloudfoundry/disaster-recovery-acceptance-tests 76 | - cloudfoundry/honeycomb-ginkgo-reporter 77 | - cloudfoundry/relint-ci-pools 78 | - cloudfoundry/relint-envs 79 | - cloudfoundry/relint-team 80 | - cloudfoundry/runtime-ci 81 | - cloudfoundry/uptimer 82 | config: 83 | generate_rfc0015_branch_protection_rules: true 84 | ``` 85 | -------------------------------------------------------------------------------- /toc/working-groups/app-runtime-platform/working-agreements/2021-10-28-how-to-make-working-agreements.md: -------------------------------------------------------------------------------- 1 | # How to Make Changes To Working Agreements 2 | 3 | Date of Forum to be Discussed: 4 | Author: Amelia Downs - @ameowlia 5 | 6 | ## Problem 7 | We have formed a working group! Now what? We need to agree on how to work 8 | together. 9 | 10 | ## Solution 11 | 1. Any approver or lead can write a new working agreement, 12 | like this one, as a PR. 13 | 1. The author will announce their proposal in the slack channel. 14 | 1. The author will present the proposal at the working group forum. 15 | 1. Anyone from the community can comment on the proposal. 16 | 1. All approvers + tech leads will have one vote to cast. They will cast their vote by 17 | replying to the PR with a "+1" or a "-1". 18 | 1. All approvers + tech leads will have one week to vote starting at the point when the 19 | proposal is discussed at the working group forum. 20 | 1. After one week the votes are counted and a simple majority wins. The tech 21 | lead will act as tie breaker. 22 | 1. If the votes are in favor of the proposal, then the PR will be merged. If the 23 | votes are not in favor, then the PR will be closed. 24 | 25 | ## FAQ 26 | 27 | 28 | -------------------------------------------------------------------------------- /toc/working-groups/app-runtime-platform/working-agreements/2021-10-29-reviewer-workflows.md: -------------------------------------------------------------------------------- 1 | # Reviewer Workflows for Issues and PRs 2 | 3 | **Date of Forum to be Discussed:** Wednesday Nov 3, 2021 9 Pacific / 12 Eastern / 17 Britain / 18 Germany 4 | See the community calendar for more details. 5 | 6 | **Author:** Amelia Downs - @ameowlia 7 | 8 | ## Problem 9 | Our working group has 70+ repos. In order to run a healthy open source community we need to make sure that we triage issues and merge PRs in a timely fashion. 10 | 11 | **As a PR author I want:** 12 | * To have my PR reviewed and merged in a timely manner. 13 | 14 | **As an issue author I want:** 15 | * To have guidance on how to fix my bug in a timely manner. 16 | 17 | **As an Approver I want:** 18 | * To know which PRs and issues I have to review. 19 | * I want to know what is expected of me as a reviewer. 20 | 21 | **As a Tech Lead I want:** 22 | * To know how many open issues and PRs there are. 23 | * To be able to assign reviews for open issues and PRs. 24 | 25 | ## Solution 26 | #### PR + Issue Tracking Github Projects for Each Sub-Group 27 | Each sub-group of our working group has a github project. 28 | These projects will contain a card for each issue and PR for the subgroup. 29 | The tech lead is responsible for assigning reviewers. 30 | The reviewers are responsible for triaging the card until either they make it to the “Done” or “Needs Fix” swimlanes. 31 | The reviewer is not responsible for fixing the bug for a given issue. 32 | 33 | **Links to Github Projects** 34 | * [App Platform - Diego](https://github.com/orgs/cloudfoundry/projects/20) 35 | * [App Platform - Garden Containers](https://github.com/orgs/cloudfoundry/projects/23) 36 | * [App Platform - Logging and Metrics](https://github.com/orgs/cloudfoundry/projects/19) 37 | * [App Platform - Networking](https://github.com/orgs/cloudfoundry/projects/24) 38 | 39 | ### Issue Workflow 40 | Below is the outline of a typical issue workflow. [See drawing](https://docs.google.com/drawings/d/1_W-Xk8pCUCv1la-rEuJAA8rE_ivMKrmxrmWyR7b0Tk4/edit?usp=sharing). 41 | 42 | 43 | ### PR Workflow 44 | Below is the outline of a typical PR workflow. [See drawing](https://docs.google.com/drawings/d/1BlIXESgk_Ycp9jRQdnY_v_qrgn2fGwCSJ-eiAssryfg/edit?usp=sharing). 45 | 46 | 47 | 48 | ## FAQ 49 | 50 | ❓ **How can I see what is assigned to me?** 51 | 1. To view all open issues assigned to you in the cf org 52 | * Go to this link when you are logged in: [https://github.com/issues/assigned?q=is%3Aopen+archived%3Afalse+org%3Acloudfoundry](https://github.com/issues/assigned?q=is%3Aopen+archived%3Afalse+org%3Acloudfoundry). 53 | 2. To view all open issues assigned to you for a particuluar project 54 | * Go to the github project. 55 | * Click on your icon on a card that is already assigned to you. 56 | * OR 57 | * Add the following query param to the URL: `?card_filter_query=assignee:YOUR-GITHUB-USERNAME`. 58 | 59 | ❓ **How much time will this take per week?** 60 | 61 | I don’t know! We are trying this for the first time and we will learn together. 62 | 63 | ❓ **As an approver, how long do I have to review something?** 64 | 65 | I am not currently setting any SLIs or SLOs. I ask that you please do your best 66 | to triage your assigned PRs and issues at least once a week. 67 | 68 | ❓ **What if I don’t think I am qualified to review something?** 69 | 70 | I ask that you try your hardest to review something. 71 | However, if you can't, that is okay. 72 | Either reach out in our working group slack channel (#wg-app-runtime-platform) and ask for 73 | someone else to review it or reach out to your tech lead and ask them to assign someone else. 74 | 75 | ❓ **What if I want to review something that is assigned to someone else?** 76 | 77 | Great! If they haven’t started on it, feel free to unassign them and assign yourself as a reviewer. 78 | 79 | ❓ **What about issues that are actually proposals?** 80 | 81 | Proposals are issues that are created and tracked in order to facilitate 82 | conversation amongst the community before a large chunk of work is started. 83 | These will be tracked in a different project ([App Platform Proposals](https://github.com/orgs/cloudfoundry/projects/22)). 84 | The workflow for this project is not flushed out yet. 85 | -------------------------------------------------------------------------------- /toc/working-groups/cf-on-k8s.md: -------------------------------------------------------------------------------- 1 | # Cloud Foundry on Kubernetes: Working Group Charter 2 | 3 | ## Mission 4 | 5 | Bring the ease and simplicity of the Cloud Foundry developer experience to Kubernetes. 6 | 7 | 8 | ## Goals 9 | 10 | - End-user developers can deploy existing Cloud Foundry-compatible applications to Kubernetes-based environments using workflows that employ official Cloud Foundry clients (such as the `cf` CLI and the CF Java client) or (v3) Cloud Foundry API calls. 11 | - End-user developers can take advantage of Cloud Foundry via Kubernetes-native APIs using existing Kubernetes tools and clients (such as `kubectl` and `client-go`). 12 | - End-user developers can smoothly migrate their workloads from their existing Cloud Foundry environments to Cloud Foundry environments on Kubernetes. 13 | - End-user operators can reuse their existing Kubernetes infrastructure and related integrations (for example, networking, identity, and observability) in their Cloud Foundry deployments. 14 | - End-users can easily try out and experiment with Cloud Foundry on Kubernetes on their own Kubernetes clusters, with a good out-of-the-box experience. 15 | - Vendors can base their own CF distributions on the core components of Cloud Foundry on Kubernetes. 16 | 17 | ## Scope 18 | 19 | - Develop the necessary components to implement the Cloud Foundry experience on top of Kubernetes. 20 | - Provide basic implementations by default for all Cloud Foundry subsystem integratios (for example, networking, identity, workload execution, and observability). 21 | - Develop a deployment of Cloud Foundry on Kubernetes that is easy to use out-of-the-box without any prior experience with Cloud Foundry. 22 | - Work with other Working Groups to make sure that existing Cloud Foundry clients (such as the `cf` CLI and the CF Java client) work with Cloud Foundry on Kubernetes out-of-the-box. 23 | 24 | ## Non-Goals 25 | 26 | - Provide full compatibility with the existing Cloud Foundry behaviour. 27 | 28 | ## Roles & Technical Assets 29 | 30 | ```yaml 31 | name: CF on K8s 32 | execution_leads: 33 | - name: Andrew Wittrock 34 | github: Birdrock 35 | technical_leads: 36 | - name: Georgi Sabev 37 | github: georgethebeatle 38 | bots: 39 | - name: korifi-bot 40 | github: korifi-bot 41 | config: 42 | generate_rfc0015_branch_protection_rules: true 43 | areas: 44 | - name: Korifi 45 | approvers: 46 | - name: Andrew Costa 47 | github: acosta11 48 | - name: Danail Branekov 49 | github: danail-branekov 50 | - name: Dave Walter 51 | github: davewalter 52 | - name: Julian Hjortshoj 53 | github: julian-hj 54 | - name: Tim Downey 55 | github: tcdowney 56 | - name: Yusmen Zabanov 57 | github: uzabanov 58 | repositories: 59 | - cloudfoundry/cf-k8s-secrets 60 | - cloudfoundry/korifi 61 | - cloudfoundry/korifi-ci 62 | ``` 63 | -------------------------------------------------------------------------------- /toc/working-groups/concourse.md: -------------------------------------------------------------------------------- 1 | # Concourse: Working Group Charter 2 | 3 | ## Mission 4 | 5 | Provides the Concourse CI/CD platform. 6 | 7 | ## Goals 8 | * Provides a stable and up to date CI/CD platform. 9 | 10 | ## Scope 11 | * Maintain public roadmaps for Concourse. 12 | * Provide the community with regular releases of Concourse. 13 | * Provide timely releases to address CVEs. 14 | * Provide the community with technical and end user documentation. 15 | * Collaborate with other working groups to continue to have first-class support with Cloud Foundry. 16 | 17 | ## Non-Goals 18 | 19 | * Require other working groups or projects to use Concourse. 20 | 21 | ## Roles & Technical Assets 22 | 23 | Technical assets for the Concourse working group are contained in the following Github Organizations: 24 | 25 | * [github.com/concourse](https://github.com/concourse) 26 | 27 | ``` 28 | name: Concourse 29 | execution_leads: 30 | - name: Derek Richard 31 | github: drich10 32 | - name: Taylor Silva 33 | github: taylorsilva 34 | technical_leads: 35 | - name: Derek Richard 36 | github: drich10 37 | - name: Taylor Silva 38 | github: taylorsilva 39 | areas: 40 | - name: Core 41 | approvers: 42 | - name: Indira 43 | github: ichandrabhatta 44 | - name: Wayne Adams 45 | github: wayneadams 46 | - name: Claire Tinati 47 | github: Spimtav 48 | - name: Harish Yayi 49 | github: yharish991 50 | reviewers: 51 | - name: Ivan Chalukov 52 | github: IvanChalukov 53 | - name: Kump3r 54 | github: Kump3r 55 | repositories: 56 | - concourse/concourse 57 | - concourse/concourse-bosh-release 58 | - concourse/ci 59 | - concourse/docs 60 | - concourse/dex 61 | - concourse/semver-resource 62 | - concourse/houdini 63 | - concourse/concourse-bosh-deployment 64 | - concourse/registry-image-resource 65 | - concourse/hg-resource 66 | - concourse/github-release-resource 67 | - concourse/bosh-io-stemcell-resource 68 | - concourse/docker-image-resource 69 | - concourse/rfcs 70 | - concourse/blog 71 | - concourse/concourse-chart 72 | - concourse/mock-resource 73 | - concourse/infrastructure 74 | - concourse/concourse-docker 75 | - concourse/git-resource 76 | - concourse/examples 77 | - concourse/flag 78 | - concourse/s3-resource 79 | - concourse/pool-resource 80 | - concourse/resource-types-website 81 | - concourse/resource-types 82 | - concourse/oci-build-task 83 | - concourse/time-resource 84 | - concourse/bosh-io-release-resource 85 | - concourse/retryhttp 86 | - concourse/prod 87 | - concourse/booklit 88 | - concourse/oxygen-mask 89 | - concourse/datadog-event-resource 90 | - concourse/office-hours #here and below is either archived, or we expect to archive in near the future 91 | - concourse/governance 92 | - concourse/.github 93 | - concourse/hush-house 94 | - concourse/tracker-resource 95 | - concourse/baggage-claim 96 | - concourse/buildroot-images 97 | - concourse/concourse-pipeline-resource 98 | ``` 99 | -------------------------------------------------------------------------------- /toc/working-groups/docs.md: -------------------------------------------------------------------------------- 1 | # Docs: Working Group Charter 2 | 3 | ## Mission 4 | 5 | To document the Cloud Foundry user experience. 6 | 7 | ## Goals 8 | 9 | - Make a plan for regular reviews and updates 10 | - Update and maintain READMEs for all docs repos 11 | - Update and maintain CF book repo/Table of Contents 12 | - Update and maintain contribution guidelines 13 | 14 | 15 | ## Scope 16 | 17 | - Merge and edit all doc changes 18 | - Update with the latest best practices for SEO and inclusive language 19 | - Maintain internal consistency of doc style, including Notes and tables, for example 20 | - Remove out-dated information (ongoing) 21 | - Advise contributors on best practices 22 | 23 | ## Non-Goals 24 | 25 | - Be responsible for component level documentation (e.g. Cloud Controller v3 docs). 26 | 27 | ## Roles & Technical Assets 28 | 29 | ```yaml 30 | name: Documentation 31 | execution_leads: 32 | - name: Anita Flegg 33 | github: anita-flegg 34 | technical_leads: 35 | - name: Anita Flegg 36 | github: anita-flegg 37 | bots: [] 38 | areas: 39 | - name: Docs 40 | approvers: 41 | - name: Anita Flegg 42 | github: anita-flegg 43 | - name: Samia Nneji 44 | github: snneji 45 | 46 | repositories: 47 | - cloudfoundry/docs-book-cloudfoundry 48 | - cloudfoundry/docs-cf-admin 49 | - cloudfoundry/docs-loggregator 50 | - cloudfoundry/docs-running-cf 51 | - cloudfoundry/docs-bbr 52 | - cloudfoundry/docs-credhub 53 | - cloudfoundry/docs-uaa 54 | - cloudfoundry/docs-buildpacks 55 | - cloudfoundry/docs-cf-cli 56 | - cloudfoundry/docs-cloudfoundry-concepts 57 | - cloudfoundry/docs-dev-guide 58 | - cloudfoundry/docs-services 59 | - cloudfoundry/docs-credhub 60 | - cloudfoundry/docs-deploying-cf 61 | - cloudfoundry/docs-dotnet-core-tutorial 62 | ``` 63 | -------------------------------------------------------------------------------- /toc/working-groups/parsable-working-groups.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | set -eu -o pipefail 4 | 5 | repo_root=$(dirname $(cd "$( dirname "${BASH_SOURCE[0]}" )/.." && pwd)) 6 | 7 | pushd $repo_root/toc/working-groups >/dev/null 8 | 9 | for group in $(ls ../*.md | grep -v -e ROLES -e CHANGEPLAN -e PRINCIPLES -e GOVERNANCE); do 10 | cat ${group} | awk '/^```yaml$/{flag=1;next}/^```$/{flag=0}flag' | \ 11 | ruby -rjson -ryaml -e "puts YAML.load(ARGF.read).to_json" 2> /dev/null | jq '[.]' 12 | done 13 | 14 | for working_group in $(ls *.md | grep -v -e WORKING-GROUPS -e paketo -e vulnerability -e concourse); do 15 | cat ${working_group} | awk '/^```yaml$/{flag=1;next}/^```$/{flag=0}flag' | \ 16 | ruby -rjson -ryaml -e "puts YAML.load(ARGF.read).to_json" 2> /dev/null | jq '[.]' 17 | done 18 | 19 | -------------------------------------------------------------------------------- /toc/working-groups/service-management.md: -------------------------------------------------------------------------------- 1 | # Service Management: Working Group Charter 2 | 3 | ## Mission 4 | 5 | Provides interfaces for service lifecycle within application platforms and adapters to common external service providers. 6 | 7 | ## Goals 8 | 9 | - Define the service extension API for Cloud Foundry brokered services. 10 | - Provide a flexible adapter layer to common hyperscaler service providers. 11 | 12 | ## Scope 13 | - Lead OSB API. 14 | - Develop and maintain Cloud Service Brokers for AWS, Azure, and GCP. 15 | - Develop and maintain ServiceFabrik, a generic BOSH-based and Docker-container-based service instance manager. 16 | 17 | ## Non-Goals 18 | 19 | ## Roles & Technical Assets 20 | Components from the Cloud Service Broker, Open Service Broker API and Service Fabrik. 21 | 22 | ```yaml 23 | name: Service Management 24 | execution_leads: 25 | - name: Marcela Campo 26 | github: pivotal-marcela-campo 27 | technical_leads: 28 | - name: Marcela Campo 29 | github: pivotal-marcela-campo 30 | bots: 31 | - name: cf-gitbot 32 | github: cf-gitbot 33 | areas: 34 | - name: Cloud Service Broker 35 | approvers: 36 | - name: George Blue 37 | github: blgm 38 | - name: Felisia Martini 39 | github: FelisiaM 40 | - name: Marcela Campo 41 | github: pivotal-marcela-campo 42 | - name: Andrea Zucchini 43 | github: zucchinidev 44 | - name: Iain Findlay 45 | github: ifindlay-cci 46 | - name: Konstantin Kiess 47 | github: nouseforaname 48 | bots: 49 | - name: Services Enablement bot 50 | github: servicesenablement 51 | repositories: 52 | - cloudfoundry/cloud-service-broker 53 | - cloudfoundry/csb-brokerpak-azure 54 | - cloudfoundry/csb-brokerpak-aws 55 | - cloudfoundry/csb-brokerpak-gcp 56 | - cloudfoundry/jdbctestapp 57 | - cloudfoundry/upgrade-all-services-cli-plugin 58 | - cloudfoundry/terraform-provider-csbpg 59 | - cloudfoundry/terraform-provider-csbmysql 60 | - cloudfoundry/terraform-provider-csbsqlserver 61 | - cloudfoundry/brokerapi 62 | config: 63 | github_project_sync: 64 | mapping: 65 | cloudfoundry: 27 66 | openservicebrokerapi: 1 67 | cloudfoundry-incubator: 3 68 | ``` 69 | -------------------------------------------------------------------------------- /toc/working-groups/vulnerability-management.md: -------------------------------------------------------------------------------- 1 | # Vulnerability Management: Working Group Charter 2 | 3 | ## Mission 4 | 5 | Provides discreet management of security vulnerabilities issues relevant for active CF projects. 6 | 7 | ## Goals 8 | 9 | * Provide a single point of contact for security vulnerability reporting and management. 10 | * Provide management of security vulnerability reports through to resolution, including but not limited to triage, reporter and team coordination, embargo negotiation, CVSS scoring, CVE assignments, pre-disclosure and disclosure. 11 | 12 | ## Scope 13 | 14 | * Triage incoming security vulnerability reports to [security@cloudfoundry.org](mailto:security@cloudfoundry.org). 15 | * Manage vulnerabilities through dedicated slack channels. 16 | * When appropriate, negotiate suitable embargo periods with the reporter to afford component teams time to fix the issue before it becomes known publicly. 17 | * When appropriate, assign CVE numbers to vulnerabilities/fixes. 18 | * Publish pre-disclosures to allow all CF distributions time to adopt fixes for high/critical vulnerabilities before they become known publicly. 19 | * Publish disclosures of reported security vulnerabilities. 20 | 21 | ## Non-Goals 22 | 23 | * Add security-related features to Cloud Foundry projects. 24 | 25 | ## Technical Lead(s): 26 | - [Paul Warren](https://github.com/paulcwarren) 27 | 28 | ## Execution Lead(s): 29 | - [Thomas Thalhofer](https://github.com/thomasthal) 30 | 31 | ## Roles & Technical Assets 32 | 33 | Security process and broadcast channels for security disclosures. 34 | 35 | * [Security Advisories](https://www.cloudfoundry.org/foundryblog/security-advisory/) 36 | * [#security](https://cloudfoundry.slack.com/archives/C0DEQSW9W) 37 | * [cff-security-pre-disclosure@cloudfoundry.org](mailto:cff-security-pre-disclosure@cloudfoundry.org) 38 | 39 | 40 | ```yaml 41 | name: Vulnerability Management 42 | execution_leads: 43 | - name: Thomas Thalhofer 44 | github: thomasthal 45 | technical_leads: 46 | - name: Paul Warren 47 | github: paulcwarren 48 | bots: [] 49 | areas: [] 50 | ``` --------------------------------------------------------------------------------