Skip to main content

Contributing via Pull Requests

Several repositories maintained by the Connected AI Platform team — for example configuration repositories, Infrastructure-as-Code repositories, or example/reference repositories — live in the connected-ai organization on GitHub Enterprise Cloud: bmw.ghe.com/connected-ai. This page explains the general workflow for proposing changes to these repositories, independent of which specific repository or CAIP stage (Managed Kubeflow or CAIP 2.0) it belongs to.

Looking for a specific example?

See PR-based Self-Service for a concrete, CAIP-specific walkthrough of using this workflow to change the products repository.

The fork-and-pull-request model​

Our contribution workflow follows GitHub's standard fork-and-pull-request model, the same model used across most GitHub organizations and open-source projects. Since you are usually not a member of the team that owns a given "internal" repository, you won't have permission to push changes directly to it. Instead, you:

  1. Create your own copy of the repository — a fork — either under your personal GitHub profile or under an organization you have permission to create repositories in.
  2. Make your changes in the fork (in a dedicated branch).
  3. Open a pull request (PR) from your fork back to the original ("upstream") repository, proposing that your changes be merged.

This lets you (and anyone else) propose changes and get feedback without needing write access to the original repository, while the repository owners stay in full control of what gets merged.

GitHub provides official documentation on this process:

Step-by-step: contributing to a connected-ai repository​

1. Fork the repository​

Navigate to the repository you want to contribute to (e.g. https://bmw.ghe.com/connected-ai/<repo>) and click Fork. Choose either your personal profile or any organization where you have permission to create repositories as the owner of the fork.

Why can I only see some repositories?

If you're not a member of the owning development team, you will only be able to see repositories flagged with "internal" visibility. This is intentional: we only allow contributions to repositories that are explicitly flagged as internal. Repositories that are private to their development team are not open for outside contributions.

2. Clone your fork and create a branch​

Clone your fork locally and create a new branch for your change:

git clone https://bmw.ghe.com/<your-username-or-org>/<repo>.git
cd <repo>
git checkout -b my-change

3. Make and commit your changes​

Apply your changes, then commit them with a clear message describing what and why.

4. Push to your fork​

git push origin my-change

5. Open a pull request against the original repository​

Open a PR from your fork's branch to the target branch (usually main) of the original connected-ai repository. You can do this either:

  • Via the GitHub UI — GitHub shows a Compare & pull request banner after you push to your fork; follow the prompts.
  • Via the GitHub CLI — run gh pr create, which creates the fork for you if it doesn't exist yet and opens the PR.

Alternatively, for small changes (e.g. a single file), you can skip the manual clone/fork steps entirely: click the edit (pencil) icon on the file in the GitHub UI, make your change, and GitHub will automatically create a fork and open the PR for you when you click Propose changes.

6. Wait for checks and review​

Most repositories run automated validation (linting, schema checks, etc.) on every PR. Once checks pass, the repository/platform team reviews and merges your PR.

Where this applies within CAIP​

This general model underlies all PR-based contribution flows across CAIP. All internal repositories in the connected-ai organization accept contributions this way, including:

  • PR-based Self-Service for Managed Kubeflow platform changes not (yet) covered by a Service Request.
  • manual — this documentation portal.
  • caip-sdk — the CAIP SDK and runtime library.
  • caip-code — instructions for setting up Coding Agents (e.g. Copilot, OpenCode, Claude, and Codex) with the CAIP LLM API.

If a specific service or repository has additional requirements (e.g. required validation checks or where to ask for help), these are documented on the corresponding service page.