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 CAP 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.
- Plugin's own GitHub repository
- capire's plugin page names opening an issue in the plugin's GitHub repository as the first support channel, then the SAP Community, then SAP Support Portal incidents; plugins by external parties such as the CAP JS community are out of scope for incidents, and capire asks to prefer public repositories and issues. cap.cloud.sap ↗
- github.com/cap-js
- GitHub organisation 'SAP Cloud Application Programming Model'; capire states that @cap-js-scoped plugins are created and maintained in shared ownership of CAP and other SAP development teams, each with its own issue tracker. github.com ↗
- CAP Community at GitHub (cap-js-community)
- GitHub organisation 'CAP Community', linked from capire's Resources page; repositories include odata-v2-adapter, websocket, event-queue and cds-cucumber. github.com ↗
- SAP Community topic page for CAP
- capire's Resources page links it as the overview of blog posts, tutorials, events and questions for CAP. pages.community.sap.com ↗
- capire docs repository
- Sources of capire (Apache-2.0); its CONTRIBUTING.md describes the 'Edit this page' button and a local setup for larger changes, and the repository has an issue tracker. github.com ↗
- cap-js/cds-types issues
- capire names this tracker for reporting incomplete @sap/cds type definitions. github.com ↗
- capire Resources and support channels
- Lists SAP Support Portal components for CDS/compiler, CAP Java and the Node.js runtime, the SAP Influence campaign for feature requests, and the community links. cap.cloud.sap ↗
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>, CAP Node.js <version>
## 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 CAP documents for tests, checks and releases is in Build a plugin, 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.