Contribute to a project
Improve a project that already does most of what you need: a fix, a test, a provider, a page of documentation. The change reaches everyone who already uses it.
Start from the artifact's page
Every artifact's page in the atlas says where it stops: its conditions, the runtimes and flavors it states, its properties and its releases, with its issue tracker linked. Read that, and the open and closed issues, before you write to the maintainer. Browse BTP/BAIP to find it.
Talk before you build
Maintainers know what they have already declined and why. A short question costs less than a pull request nobody asked for.
- terraform-provider-btp Discussions
- Q&A, ideas, announcements and show-and-tell for the Terraform provider github.com ↗
- terraform-provider-btp Issues
- Bug reports and feature requests for the provider github.com ↗
- btp-terraform-samples Discussions
- Questions on the Terraform samples, linked from the repository README github.com ↗
- Kyma at SAP (SAP Community topic page)
- Links to asking Kyma questions on SAP Community and to the Kyma open-source Slack and GitHub pages.community.sap.com ↗
- kyma-project on GitHub
- Open-source Kyma modules, the BTP manager, the Terraform module and community modules github.com ↗
- SAP Architecture Center Community of Practice
- Feedback through GitHub issues and discussions on reference architectures architecture.learning.sap.com ↗
- Project Piper (SAP/jenkins-library)
- Community support for the CI/CD library through GitHub issues and pull requests, per project-piper.io github.com ↗
- SAP-docs/btp-cloud-platform
- Issues and pull requests against the Markdown source of the SAP BTP documentation github.com ↗
Open a good issue with the original project
Describe the need, not your solution. Link the evidence you found, including what the atlas records, so the maintainer can check it instead of taking it on trust.
- The use case.
- What you are trying to do, and in which runtime or flavor.
- What you found.
- Which artifacts you looked at and where each stops. Link the sources, not only the atlas page.
- A minimal reproduction.
- Versions, configuration, the smallest project that shows it.
- What you could do.
- Only if you mean it: a test, docs, a patch. Leave the decision to the maintainer.
- Leave out
- comparisons with competing projects and claims of demand you cannot show.
## Use case
<what you want to do>, SAP BTP <Cloud Foundry|Kyma>, <region>
## What exists
- <artifact>: stops at <limit> (<source link>)
- atlas record: <url> (checked <date>)
## Reproduction
<smallest project, config, steps>
## I could help with
<tests | docs | a patch | nothing yet>Bring the project's own checks
A change is reviewed against the tests, checks and documentation the project already has. Run them before you open the pull request, and add a test for what you changed. What BTP/BAIP documents for tests, checks and releases is in Build a reusable deployment, with the extension points a change is likely to touch.
After it is merged
The change reaches people with the project's next release. Once it is released, the atlas can record what it now covers: correct the entry, or tell the atlas through Feedback, with the release as the source.