Skip to content

Latest commit

 

History

History
174 lines (109 loc) · 7.86 KB

CONTRIBUTING.md

File metadata and controls

174 lines (109 loc) · 7.86 KB

How to contribute

At Innoactive we want to thank you for being part of this community and helping us to improve the Creator.

There are many ways to contribute, it could be by suggesting new features and ideas, reporting bugs, extending and modifying functionalities, and even from just using the Creator and developing amazing VR training applications.

In this guide, we summarize how you can do all those actions.

Table of Contents:

  1. Getting Started
  2. Code of Conduct
  3. Feature Request
  4. Bug Report
  5. Submitting Changes
  6. Maintainers
  7. Coding Conventions
  8. Source Control Commit Guidelines
  9. Contributors

Getting Started

The easiest and simplest way to get started and try out the Creator is by downloading the latest version from our resources site.

Make sure to read the documentation for a deeper understanding of how the tool works.

Code of Conduct

This project and everyone participating in it are governed by the Innoactive Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to our maintainers.

Feature Request

We are keen to listen to your feature requests.

To request a feature, please go to the Issues section of this repository and create a new issue using the Feature request template. Be as detailed as possible, if possible, try to include references, and explain what is the benefit of the feature.

Make sure your idea is unique using the search functionality. If a similar feature request already exists, try providing additional information instead of creating a new issue.

In the case that a similar feature request already exits but is closed without being resolved, you are welcome to create a new one if you think it makes sense.

Bug Report

If you find an error in the source code, or experience one when using the Creator, you can help us by submitting a bug report issue to our GitHub issue tracker.

Before submitting a new bug report, make sure there has not been reported already by using the search functionality in the issues section of this repository.

To report a new bug, please go to the Issues section of this repository and create a new issue using the Bug report template. Be as detailed as possible, explain how to reproduce it, if possible, try to include references and rate of reproducibility.

You can also submit a Pull Request with a fix!

Creating comprehensive bug reports helps the community to quickly understand the problem and the severity.

If you find a security vulnerability, do NOT open an issue. Contact a maintainer instead.

Alternatively, customers can contact us directly using our support channel.

Submitting Changes

By default, this repository is protected, the only way to submit changes is by merging via creating a pull request from a fork, this is only intending to provide the best quality and add a security layer, we could detect and prevent new bugs, breaking functionalities and avoid violations to our code convention.

Use the pull request template for detail as much as possible all the changes included in the pull request, this way it is easier for everyone to review.

Make sure to also follow the Source Control Commit Guidelines.

See more about Pull Requests and how to fork a repository.

Maintainers

Meet out maintainers:

tomwim
Thomas W.

Maintainers are responsible for this repository and its community.

Coding Conventions

By encouraging coding conventions we ensure:

  • The code to having a consistent look, so that readers can focus on content, not layout.
  • Enabling readers to understand the code more quickly by making assumptions based on previous experience.
  • Facilitating copying, changing, and maintaining the code.
  • Sticking to C# best practices.

Please follow our Coding Conventions.

Source Control Commit Guidelines

When committing to an Innoactive git project, please adhere to the Conventional Commits. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate automated release notes.

Commit Message Format

Every commit message consists of a header (mandatory), a body, and a footer.
The header has a special format that includes a type and subject:

<type>: <subject>

[optional body]

[optional footer(s)]

Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

The footer should contain a closing reference to an issue if any.

Revert

If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

Type

Must be one of the following:

  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs)
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests

Subject

The subject contains a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize the first letter
  • no dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Footer

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Examples:

Commit message with no body

docs: update changelog to beta.5

Commit message with both

fix: need to depend on latest rxjs and zone.js

The version in our package.json gets copied to the one we publish, and users need the latest of these.

Commit message with multi-paragraph body and multiple footers

fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

See more Conventional Commits Examples

Contributors

Thank you all for your help, we appreciate all your contributions.