First off, thank you for considering contributing to this project.

Following these guidelines helps to communicate that you respect the time of the developers managing and creating this project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests. We created these guidelines to ensure that everyone has the same information when working on the project.

• Please don’t use the issue tracker for support questions. We have a dedicated Service Desk for these questions:

• Please check whether the FAQ can help with your issue. This can be found via our AnswerOverflow or Service Desk.

• Please check the closed tickets & pull requests before opening an new one.

In order to determine whether you are dealing with a security issue, ask yourself these two questions:

• Can I access something that’s not mine, or something I shouldn’t have access to?

• Can I disable something for other people?

If the answer to either of those two questions are "yes", then you’re probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you’re unsure, just contact us.

We prioritize any security issue brought to our attention, dedicating all available resources to ensure it’s handled swiftly. Security is one of the most important steps in all of our processes, and we follow the OSS Best Practices to reduce the chances of these issues occurring.

We have a Contributor License Agreement which can be found at @Eventiva/CODE_OF_CONDUCT.

You must have agreed to the code of conduct and DCO before your contributions can be included.

• Ensure cross-platform compatibility for every change that’s accepted.

• Ensure that code meets all requirements

• Submit and Ensure each contribution is created on its own branch to ensure we can follow Semantic Versioning

• Be welcoming to newcomers and encourage diverse new contributors from all backgrounds

Unsure where to begin contributing? You can start by looking through these beginner and help-wanted issues:

• First Timers - issues specific for first time github users, designed and created to guide you through contributing.

• Beginner issues - issues which should only require a few lines of code, and a test or two.

• Help wanted - issues which should be a bit more involved than beginner issues.

When you believe you have completed your contribution, you will need to make an pull request. This should be simple for most users, and we have provided some templates for you to get started, however if you choose to create your pull request from scratch, please ensure the following steps are followed.

Small contributions such as fixing spelling errors, where the content is small enough to not be considered intellectual property, can be submitted by a contributor as a minor patch, without a CLA.

As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following:

• Spelling / grammar fixes

• Typo correction, white space and formatting changes

• Comment clean up

• Issue fixes that change default return values or error codes stored in constants

• Adding logging messages or debugging output

• Changes to �metadata� files like Gemfile, .gitignore, build scripts, etc.

• Moving source files from one directory or package to another

Standard contributions are contributions which are too large to be considered a minor contribution however, only address one feature or function. This can include, but is not limited to, tutorials, wiki pages, new features (e.g. small integrations) and feature enhancements. Our automation systems will automatically do all the hard work of labeling, assigning and reviewing your contribution.

You are required to sign the CLA and agree to the terms. This will be automatically handled by our automation when you create a pull request, and once signed you will be able to submit without resigning.

Major contributions are contributions which add, modify or remove multiple features or modules. We can not emphasize enough how much the community helps us every time they submit one of these.

You are required to sign the CLA and agree to the terms. This will be automatically handled by our automation when you create a pull request, and once signed you will be able to submit without resigning.

Please follow the branch name configuration defined as follows:

• Chore: chore/

• Enhancement: enhance/

• Feature: feat/

• Documentation: docs/

• Bug: fix/

• Optimisation: opt/

• Deprecate: dep/

• Refactor: ref/

• Style: style/

If you are working on a issue which is tracked in the roadmap or issue trackers, please ensure to use the branch name and issue id so that the commits can be linked to the issue.

Code review is a complex process which we undertake over multiple locations to ensure that the code complies with all our current expectations and goals. There are a number of resources which we utilise to ensure the pull request is handled as fairly as possible.

• Bit.cloud - Utilized to compare how the proposed version will affect other components and simulate changes across all components that are affected.

• Discord - Utilized to communicate regarding the proposed changes in a free flowing manor, with quick feedback and immediate response times.

• GitHub - Utilized to manage the proposed changes, run security checks, run automations, track review approvals and change requests.

Once you have submitted a pull request, the following processes are automated:

• Initial Review: A initial Automatic Review is handled by @CodderRabitAI, which will write out a Summary of your submitted changes, provide a walkthrough of the changes in a comment and mark any suggested improvements. These suggested changes should be taken as seriously as a real developer telling you to make the changes. If you disagree with any of the suggestion, simply leave a comment and let us know.

• Code Analysis: SonarCloud will provide a quality control analysis of the code. You should fix any and all issues which this highlights.

• Branch Preview: Bit will automatically release a new Lane and publish it to Bit.Cloud. This will allow you to preview your components and test how the changes you made will affect other elements.

• Checks: A number of security, code and build steps (20+ at time of writing) will run on your branch. Until these have completed your code can not be merged.

Before you move to manual review from our team, you will have a chance to utilize SweepAI, which will automatically work on improving things for you. SweepAI takes all our complex code rules and ensures the changes comply to the best standard possible.

Manual Review then takes place. One of our developers will review the code you’ve submitted. The developer will be assigned to the Pull Request. The CodeOwners for the files will also be requested to review.

Once all required persons have submitted reviews, the senior developer involved will be required to add the successful Pull Request to the merge queue, which will run some more checks to ensure the code hasn’t changed then merge it with a Squash Merge.