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 ABAP 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.
- abapGit issues
- The abapGit README directs questions, comments, bugs, feature requests and wishes to an issue here. github.com ↗
- abaplint issues
- Issue tracker of the abaplint linter and its rules. github.com ↗
- Clean ABAP (SAP/styleguides) issues
- Where the style guide is discussed; the guide has a section "How to Disagree". github.com ↗
- dotabap.org list
- The list behind dotabap.org of ABAP open-source projects on GitHub. Each listed project's own repository and issue tracker is where to raise a question about it. github.com ↗
- SAP Community: ABAP Development tag
- Questions, discussions and blog posts tagged ABAP Development. community.sap.com ↗
- SAP Community: ABAP Development topic page
- SAP Community's topic page for ABAP, linking related topics such as ABAP Extensibility and the BTP ABAP environment. pages.community.sap.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>, ABAP <release>, Standard ABAP
## 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 ABAP documents for tests, checks and releases is in Build an abapGit project, 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.