Propose addition of Concourse working group

[drich10]

👋 We'd like to propose inclusion of the Concourse project in the CFF, and in service of that, create a working group to develop and maintain the future of it. Concourse has been an integral part of Cloud Foundry's CI/CD story and we'd love to keep these projects in close proximity.

With respect to the folks listed in the PR, this is an initial list of known contributors we expect to be a part of the project. We are open to additional members within the group 🙏 .

We'd like to migrate to the CFF's processes and tooling for governance as Concourse is onboarded and the tooling is updated to handle repositories in separate Github organizations.

[linux-foundation-easycla]

• ❌ - login: @drich10 / name: Derek Richard . The commit (cefeaf7, 3b88242, 7144342) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[rkoster]

@drich10 could you make your pivotal-cf org membership public: https://github.com/orgs/pivotal-cf/people?query=drich10
This should resolve the EasyCLA issue.

[richo6030]

Hi everyone,

I’m very pleased to see the discussion around creating this working group to bring Concourse into the CF Foundation. This is an important step, and I'm excited about the direction this could take.

As part of the BTP CF Concourse team at SAP, we’ve been closely involved with Concourse for a long time. Personally, I've been a user of Concourse since 2016 and an active member of this internal team since 2019, working to provision and support Concourse instances across all SAP BTP CF landscapes. Given our extensive experience, we’re excited about continuing to collaborate with the wider community.

I would also like to propose two colleagues from my team, Kump3r and IvanChalukov, as potential contributors for reviewer roles in the Concourse project. They’ve worked on various complex challenges, including building Concourse and troubleshooting issues across network layers, databases, and more. They are currently leading two key community-driven efforts: FIPS compliance for Concourse and supporting CF API V3. These are ongoing PRs where they are the main contributors:

• FIPS Enablement for Concourse
  • Contributor: Ivan Chalukov
• Concourse Dex Migration to CF API V3
  • Contributor: Kump3r

I’m confident that they have the development expertise and commitment to play an active role in the community and help drive Concourse forward. They’re eager to contribute more deeply and continue collaborating with the community to ensure a bright future for Concourse.

Kind Regards,
Hristo

[stephanme]

Some technical aspects regarding org automation because the proposal talks about projects in the github org concourse:

As of today, the CF org automation can't handle multiple github organizations and assumes that all repositories, org members and teams are part of the cloudfoundry org. If the org automation shall handle multiple github orgs in future, it needs extensions like specifying the github org per WG, a concept how to translate 'contributors' into github org members and probably more. Also some RFCs explicitly mention the cloudfoundry org, e.g.:

• https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0002-github-members.md
• https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0007-repository-ownership.md
• https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0014-github-teams-and-access.md
• also: https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md

Until the org automation supports multiple github orgs, the new WG needs to be excluded from the org automation. The easiest way would be to change the yaml code block into an untyped code block (the org automation searches for "```yaml")