Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(Structure): add default github documentation and standard readme
The default set of GitHub docs has been added to provide automated links within GitHub to important information. The `README.md` has been updated to contain basic information for the moment and a `.gitignore` file has been added to ignore basic system files.
- Loading branch information
1 parent
fff0de7
commit a9d382d
Showing
6 changed files
with
335 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
# Code of Conduct | ||
|
||
Contact: hello@vrtk.io | ||
|
||
## Why have a Code of Conduct? | ||
|
||
As contributors and maintainers of this project, we are committed to providing a friendly, safe and welcoming environment for all, regardless of age, disability, gender, nationality, race, religion, sexuality, or similar personal characteristic. | ||
|
||
The goal of the Code of Conduct is to specify a baseline standard of behavior so that people with different social values and communication styles can talk about VRTK effectively, productively, and respectfully, even in face of disagreements. The Code of Conduct also provides a mechanism for resolving conflicts in the community when they arise. | ||
|
||
## Our Values | ||
|
||
These are the values VRTK developers should aspire to: | ||
|
||
* Be friendly and welcoming | ||
* Be patient | ||
* Remember that people have varying communication styles and that not everyone is using their native language. (Meaning and tone can be lost in translation.) | ||
* Be thoughtful | ||
* Productive communication requires effort. Think about how your words will be interpreted. | ||
* Remember that sometimes it is best to refrain entirely from commenting. | ||
* Be respectful | ||
* In particular, respect differences of opinion. It is important that we resolve disagreements and differing views constructively. | ||
* Avoid destructive behavior | ||
* Derailing: stay on topic; if you want to talk about something else, start a new conversation. | ||
* Unconstructive criticism: don't merely decry the current state of affairs; offer (or at least solicit) suggestions as to how things may be improved. | ||
* Snarking (pithy, unproductive, sniping comments). | ||
|
||
The following actions are explicitly forbidden: | ||
|
||
* Insulting, demeaning, hateful, or threatening remarks. | ||
* Discrimination based on age, disability, gender, nationality, race, religion, sexuality, or similar personal characteristic. | ||
* Bullying or systematic harassment. | ||
* Unwelcome sexual advances. | ||
* Incitement to any of these. | ||
|
||
## Where does the Code of Conduct apply? | ||
|
||
If you participate in or contribute to the VRTK ecosystem in any way, you are encouraged to follow the Code of Conduct while doing so. | ||
|
||
Explicit enforcement of the Code of Conduct applies to the official mediums operated by the VRTK project: | ||
|
||
* The official GitHub projects and code reviews. | ||
* The official VRTK slack channel. | ||
|
||
Other VRTK activities (such as conferences, meetups, and other unofficial forums) are encouraged to adopt this Code of Conduct. Such groups must provide their own contact information. | ||
|
||
Project maintainers may remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. | ||
|
||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing: hello@vrtk.io. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. **All reports will be kept confidential**. | ||
|
||
**The goal of the Code of Conduct is to resolve conflicts in the most harmonious way possible**. We hope that in most cases issues may be resolved through polite discussion and mutual agreement. Bannings and other forceful measures are to be employed only as a last resort. **Do not** post about the issue publicly or try to rally sentiment against a particular individual or group. | ||
|
||
## Acknowledgements | ||
|
||
This document was based on the Code of Conduct from the Elixir project. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,211 @@ | ||
# Contributing | ||
|
||
We are keen for developers to contribute to open source projects to | ||
keep them great! | ||
|
||
Whilst every effort is made to provide features that will assist a wide | ||
range of development cases, it is inevitable that we will not cater for | ||
all situations. | ||
|
||
Therefore, if you feel that your custom solution is generic and | ||
would assist other developers then we would love to review your | ||
contribution. | ||
|
||
There are however, a few guidelines that we need contributors to | ||
follow so that we can have a chance of keeping on top things. | ||
|
||
## Getting Started | ||
* Make sure you have a GitHub account. | ||
* Create a new issue on the GitHub repository, providing one does | ||
not already exist. | ||
* Clearly describe the issue including steps to reproduce when it | ||
is a bug (fill out the issue template). | ||
* Make sure you fill in the earliest version that you know has | ||
the issue. | ||
* Fork the repository on GitHub. | ||
|
||
## Making Changes | ||
|
||
* Create a topic branch from where you want to base your work. | ||
* If you're fixing a bug then target the `master` branch. | ||
* If you're creating a new feature then target the next release | ||
branch. The current next release branch is `3.3.0-alpha`. | ||
* Name your branch with the type of issue you are fixing; | ||
`feat`, `chore`, `docs`. | ||
* Please avoid working directly on your master branch. | ||
* Make sure you set the `Asset Serialization` mode in | ||
`Unity->Edit->Project Settings->Editor` to `Force Text`. | ||
* Make commits of logical units. | ||
* Make sure your commit messages are in the proper format. | ||
|
||
Following the above method will ensure that all bug fixes are pushed | ||
to the `master` branch while all new features will be pushed to the | ||
relevant next release branch. This means that patch releases are | ||
much easier to do as the `master` branch will only contain bug fixes | ||
so will be used to fork into new patch releases. Then master will be | ||
rebased into the relevant next release branch so the next release also | ||
contains the updated bug fixes in the previous patch release. | ||
|
||
## Coding Conventions | ||
|
||
To ensure all code is consistent and readable, we adhere to the | ||
default coding conventions utilised in Visual Studio. The easiest | ||
first step is to auto format the code within Visual Studio with | ||
the key combination of `Ctrl + k` then `Ctrl + d` which will ensure | ||
the code is correctly formatted and indented. | ||
|
||
Spaces should be used instead of tabs for better readability across | ||
a number of devices (e.g. spaces look better on Github source view.) | ||
|
||
In regards to naming conventions we also adhere to the standard | ||
.NET Framework naming convention system which can be | ||
[viewed online here](https://msdn.microsoft.com/en-gb/library/x2dbyw72(v=vs.71).aspx) | ||
|
||
Class methods and parameters should always denote their accessibility | ||
level using the `public` `protected` `private` keywords. | ||
|
||
> **Incorrect:** | ||
``` | ||
void MyMethod() | ||
``` | ||
|
||
> **Correct:** | ||
``` | ||
private void MyMethod() | ||
``` | ||
|
||
All core classes should be within the relevant `VRTK` namespace. | ||
|
||
Parameters should be defined at the top of the class before any methods | ||
are defined. | ||
|
||
It is acceptable to have multiple classes defined in the same file as | ||
long as the subsequent defined classes are only used by the main class | ||
defined in the same file. | ||
|
||
Where possible, the structure of the code should also flow with the | ||
accessibility level of the method or parameters. So all `public` | ||
parameters and methods should be defined first, followed by `protected` | ||
parameters and methods with `private` parameters and methods being | ||
defined last. | ||
|
||
Blocks of code such as conditional statements and loops must always | ||
contain the block of code in braces `{ }` even if it is just one line. | ||
|
||
> **Incorrect:** | ||
``` | ||
if (this == that) { do; } | ||
``` | ||
|
||
> **Correct:** | ||
``` | ||
if (this == that) | ||
{ | ||
do; | ||
} | ||
``` | ||
|
||
Any method or variable references should have the most simplified name | ||
as possible, which means no additional references should be added where | ||
it's not necessary. | ||
|
||
> `this.transform.rotation` *is simplified to* `transform.rotation` | ||
> `GameObject.FindObjectsOfType` *is simplified to* `FindObjectsOfType` | ||
All MonoBehaviour inherited classes that implement a MonoBehaviour | ||
[Message](https://docs.unity3d.com/ScriptReference/MonoBehaviour.html) | ||
method must at least be `protected virtual` to allow any further | ||
inherited class to override and extend the methods. | ||
|
||
## Documentation | ||
|
||
All core scripts, abstractions, controls and prefabs should contain | ||
inline code documentation adhering to the .NET Framework XML | ||
documentation comments convention which can be | ||
[viewed online here](https://msdn.microsoft.com/en-us/library/b2s063f7.aspx) | ||
|
||
Public classes, methods, delegate events and unity events should be | ||
documented using the XML comments and contain a 1 line `<summary>` | ||
with any additional lines included in `<remarks>`. | ||
|
||
Public parameters that appear in the inspector do not need XML | ||
comments and just require a `[Tooltip("")]` which is used to generate | ||
the documentation. However, other public class variables that are | ||
hidden from the inspector do need XML style comments to document them. | ||
|
||
## Commit Messages | ||
|
||
All pull request commit messages are automatically checked using | ||
[GitCop](http://gitcop.com) - this will inform you if there are any | ||
issues with your commit message and give you an opportunity to rectify | ||
any issues. | ||
|
||
The commit message lines should never exceed 72 characters and should | ||
be entered in the following format: | ||
|
||
``` | ||
<type>(<scope>): <subject> | ||
<BLANK LINE> | ||
<body> | ||
<BLANK LINE> | ||
``` | ||
|
||
### Type | ||
|
||
The type must be one of the following: | ||
|
||
* feat: A new feature. | ||
* fix: A bug fix. | ||
* docs: Documentation only changes. | ||
* refactor: A code change that neither fixes a bug or adds a feature. | ||
* perf: A code change that improves performance. | ||
* test: Adding missing tests. | ||
* chore: Changes to the build process or auxiliary tools or | ||
libraries such as documentation generation. | ||
|
||
### Scope | ||
|
||
The scope could be anything specifying the place of the commit change, | ||
such as, `Controller`, `Interaction`, `Locomotion`, etc... | ||
|
||
### Subject | ||
|
||
The subject contains succinct description of the change: | ||
|
||
* use the imperative, present tense: "change" not "changed" nor | ||
"changes". | ||
* don't capitalize first letter, unless naming something, such as | ||
`Bootstrap`. | ||
* no dot (.) at the end of the subject line. | ||
|
||
### 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. References to | ||
previous commit hashes is actively encouraged if they are relevant. | ||
|
||
> **Incorrect commit summary:** | ||
``` | ||
Added feature to improve teleportation | ||
``` | ||
> **Incorrect commit summary:** | ||
``` | ||
feat(Teleport): Add feature | ||
``` | ||
> **Incorrect commit summary:** | ||
``` | ||
feat(my-teleport-feature): my feature. | ||
``` | ||
|
||
> **Correct commit summary:** | ||
``` | ||
feat(Teleport): add fade camera option on teleport | ||
``` | ||
|
||
## Submitting Changes | ||
* Push your changes to your topic branch in your repository. | ||
* Submit a pull request to this repository. | ||
* The core team will aim to look at the pull request as soon as | ||
possible and provide feedback where required. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
> **NOTE:** Any issue that does not follow the below template will be immediately closed and not re-opened until the template structure is adhered to. | ||
### Precheck | ||
|
||
* Do not use the issues tracker for help or support (try VRTK Slack channel, Stack Overflow, etc.) | ||
* For proposing a new feature, please check existing open and closed issues before creating a duplicate | ||
* For bugs, do a quick search and make sure the bug has not yet been reported | ||
* Finally, be excellent to each other, and party on dudes! | ||
|
||
### Environment | ||
|
||
* Source of VRTK (Unity Asset Store or Github) | ||
* Version of VRTK (Unity Asset Store/Github release number) (Github master commit hash) | ||
* Version of Unity3D (e.g. Unity 2018.1) | ||
* Hardware used (e.g. Vive/Oculus) | ||
* SDK used (e.g. OpenVR/SteamVR/Oculus Utilities) | ||
|
||
### Steps to reproduce | ||
|
||
Attempt to recreate the issue in a VRTK example scene and provide steps to reproduce in a clear text step by step list. Include code samples, errors and stacktraces if appropriate. | ||
|
||
> Do not upload custom projects with custom code to demonstrate the issue. | ||
### Expected behavior | ||
|
||
Briefly describe what you expect should happen | ||
|
||
### Current behavior | ||
|
||
Briefly describe what is actually happening |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
Only submit an issue if you have a known bug or are requesting a new feature. | ||
|
||
If you require help or support then ask a question in the official VRTK Slack channel at http://invite.vrtk.io |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
# System files | ||
.DS_Store | ||
*.swp |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,33 @@ | ||
# VRTK.Unity.Core | ||
A set of design patterns for rapidly building VR solutions in Unity3d | ||
![image](https://user-images.githubusercontent.com/1029673/39358522-3d16a6aa-4a0e-11e8-9515-41909f36e70d.png) | ||
|
||
> ### VRTK.Unity.Core | ||
> A set of design patterns for rapidly building VR solutions in Unity3d | ||
[![Slack](http://sysdia2.co.uk/badge.svg)](http://invite.vrtk.io) | ||
[![Documentation](https://img.shields.io/badge/readme-docs-3484C6.svg)](http://docs.vrtk.io) | ||
[![Twitter Follow](https://img.shields.io/twitter/follow/vr_toolkit.svg?style=flat&label=twitter)](https://twitter.com/VR_Toolkit) | ||
[![YouTube](https://img.shields.io/badge/youtube-channel-e52d27.svg)](http://videos.vrtk.io) | ||
[![Waffle](https://img.shields.io/badge/project-backlog-78bdf2.svg)](https://waffle.io/ExtendRealityLtd/VRTK.Unity.Core) | ||
|
||
## 3<sup>rd</sup> Party SDK Support | ||
|
||
* [VRTK.Unity.SteamVR] | ||
* [VRTK.Unity.OculusUtilities] | ||
|
||
## Introduction | ||
|
||
VRTK.Unity.Core is a core collection of design patterns for Unity | ||
that can be beneficial in VR development. | ||
|
||
## Contributing | ||
|
||
We're not currently in a place where accepting contributions would | ||
be helpful. But as soon as we're ready we'll let you know! | ||
|
||
## License | ||
|
||
Code released under the [MIT License]. | ||
|
||
[MIT License]: LICENSE.md | ||
[VRTK.Unity.SteamVR]: https://github.com/ExtendRealityLtd/VRTK.Unity.SteamVR | ||
[VRTK.Unity.OculusUtilities]: https://github.com/ExtendRealityLtd/VRTK.Unity.OculusUtilities |