Contribute

Contribute 📝

We welcome contributions and feedback from everyone! There are different ways you can contribute to the Renku UI project.

Report a bug 🐛

Did you find something that doesn't work as expected? Did you spot any typos or broken links?

Whatever the problem you found, please start a new 🐛 bug discussion in the Discussions section section here on GitHub. The more details you provide, the easier it is for us to identify and address the problem properly.

We encourage using the Discussions section over the Issues section for bug reports, as it allows for a more interactive and detailed conversation. A maintainer will care about opening issues with all the details so developers can work on them.

Suggest new ideas 💡

We are open to new ideas and encourage you to share them!

If you have a suggestion for a new feature, a new component, or a new interaction, please start a new 💡 idea discussion in the Discussions section section here on GitHub.

If you need help shaping your idea or prefer to contact us first, you can email us at [email protected]. There are other ways to reach us; feel free to pick the one you prefer.

Open a Pull Request 📤

Code contributions are very welcome! You can pick any issue from the Issues section. We keep that list curated so that all entries are actionable, but feel free to ask in a comment when in doubt. All issues marked as Cooldown should be relatively short. In contrast, the ShapeUp issues are bigger undertakings and are usually assigned to maintainers as they might require coordination with people on the backend, product, or design team.

There is no need for a reference issue for trivial fixes like correcting typos or adjusting classes. More significant changes that do not reference an issue should be first discussed in the Discussions section section here on GitHub or directly with a maintainer.

Write code 👨‍💻

If you wish to contribute new Pull requests, your code must satisfy specific standards we have set to simplify collaboration with the broader community. Please refer to the Develop section for further information.

Commit and push 📌

When you are ready to submit your changes, please open a Pull Request. We require you to follow the Conventional Commits standard for your commit messages. This will help us generate a proper changelog when we release. Here are the rules:

• Start the commit message with a type from the following list (taken from the Angular convention: build, ci, docs, feat, fix, perf, refactor, style, test, chore. Do not add any scope.
• Write a concise description of the change starting with a verb in the present tense (imperative mood).
• [optional] Use the body of the commit message to provide more context about the change. Not necessary for things like typos, version bumps, or simple fixes.
• [optional] Include a footer if you wish to reference issues or include co-authors.
• Mention breaking changes whenever the UI crashes or is partially unusable without new backend components (typically API changes). Add an exclamation mark after the type, and describe the change after the body using the words BREAKING CHANGE: followed by [component_name] > [current_version].
  Should the final version number differ in the backend, we can amend it in the GitHub release notes.
• Include a reference to the PR number at the end of the description (first line). If you use "squash-merge" on GitHub, this will be added automatically.

Deploy and merge 🔀

Once you open a Pull Request, the CI will run the tests and check the code style. To ensure the code doesn't introduce regressions anywhere else in the platform and simplify the reviewer's life, we have an automatism to deploy the PR changes into a temporary environment.

If you are an external contributor, you might not have all the necessary rights, but this shouldn't be a concern for you; a maintainer will still review your changes and, whenever required, merge the PR first to a feature branch to run all the platform-wide tests.

To deploy the changes, you need to include a line with the text /deploy in the description of the PR. That will deploy a dev instance of Renkulab reachable at the URL https://renku-ci-ui-<PR_number>.dev.renku.ch/. The process takes a few minutes and Renku Bot will post the exact URL. The deployment can be further customized (renku-action reference), which is necessary whenever your code depends on backend changes.

If everything is fine, a maintainer will review your changes and merge them into the main branch. Maintainers are asked to ensure the Cypress-based acceptance tests in the Renku repository are still compatible with the changes; they must be updated as part of the contribution flow.

Mind that your code will be licensed as Apache 2.0.

Release 🚢

We regularly release new versions of the Renku UI. We don't have a fully automated process, but that happens within weeks (at worst).

We use GitHub automatisms to generate the changelog based on the commit messages, pick a new tag, and add names to the Contributors list in the Releases page.

When does your change land on RenkuLab? After the Renku UI release, a maintainer will bump the section ui.client.image.tag in the values.yaml file in the Renku repository. A release manager will take care of the Renku release within a few days and, shortly after tagging, the DevOps team will deploy it on renkulab.io.