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 UI5 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.
- OpenUI5 issues
- Bug reports and feature requests for the framework; CONTRIBUTING.md asks that support questions go to Stack Overflow (tag sapui5) or SAP Community instead. github.com ↗
- OpenUI5 CONTRIBUTING.md
- Bug report guidelines, feature request template, DCO for code contributions. github.com ↗
- OpenUI5 Slack (sign-up)
- Linked from the OpenUI5 README and the ui5-community profile; the ecosystem showcase names its #tooling channel, wdi5 its #wdi5 channel. ui5-slack-invite.cfapps.eu10.hana.ondemand.com ↗
- ui5-community discussions
- GitHub Discussions of the community org that hosts UI5 libraries, controls and CLI extensions. github.com ↗
- UI5 Ecosystem Showcase issues
- Where to raise a UI5 CLI task or middleware before contributing it to the monorepo. 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>, UI5 <version>, Fiori elements
## 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 UI5 documents for tests, checks and releases is in Build a library or extension, 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.