Contributing to Talenra

Introduction

Thank you for considering contributing to Talenra!

There are several ways to contribute.

• Merge requests are the best way to propose changes to the codebase (fixes, features).
• Bug reports are important to improve quality. If you discover a problem, please take some time to investigate and report!

Setup and workflow

GitLab – our homebase

We use GitLab hosted at Talenra to host code, to track issues and feature requests and to manage merge requests.

Git-flow workflow

We work according to the git-flow workflow model. Branch names match the original git-flow proposal except for master which is named main in our repository.

We use v as version tag prefix (e.g. release 1.0.0 is tagged v1.0.0). Using the prefix makes searching for tags easier.

Open a merge request

Merge requests (MR) are the best way to propose changes to the codebase. We actively welcome your MRs and you can issue a MR at any time.

Feel free to open a feature request at GitLab's issue tracker and describe your idea before you invest effort and time on a code change or a new feature. Your issue will serve as the basis to

• discuss your plans with the core team to ensure they align with the scope and the roadmap.
• align your efforts with those of the community and the core team.

Be aware that all merge requests run through a code review and, if they affect the visual interface, an additional design review. So be prepared to improve your request based on the feedback of the core developers and designers. We do our best to support you to get your request merged.

• Clone the repo and create your feature branch (e.g. feature/#[issue-number]-name) from develop.
• Keep your changes as compact as possible (one single feature/fix per merge request)
• If you've changed APIs, update the documentation and add a note in the changelog (in section "Unreleased")
• If your code can be showcased, add a showcase to the demo app.
• Avoid breaking changes. If you have to introduce breaking changes include a transitional solution to support the current API, include a deprecation warning (console) and explain it in the upgrade guide. Both might be removed with the next major release.
• Write unit and end-to-end tests.
• Open a merge request early! GitLab's merge request feature offers a great platform to discuss code changes. Explain your changes as precise and briefly as possible. Checklists are typically a good form. Add notes if it might help the reviewers to understand your decisions.

We're here to help (s. contact)!

Bug reports

If you found a security vulnerability, do NOT open an issue. Contact the core team via private message or email instead.

If you found a bug, please take a moment to open a new issue at GitLab's issue tracker (use the label "bug").

A solid bug report typically includes the following information.

• Summary
• Environment: What version of the library are you using? Describe the environment affected (e.g. operating system, browser), include version numbers.
• Steps to reproduce: Be as precise as possible and include sample code. Make sure you can reproduce the bug reliably.
• Description of the expected result
• Description of actual result: Screenshots (with annotations) are often helpful.
• Comments: e.g. Do you have an idea why it is not working as expected? What did you try to make it work?

Licence

Any contributions you make will be under the same license that covers the project.

Community

Connect with the community (s. contact)!