Merge develop into master

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,73 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [contact@daque.me](mailto:contact@daque.me?Subject=Code%20of%20Conduct%20Report).
+All complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org

.github/CONTRIBUTING.md

@@ -0,0 +1,177 @@
+# Contributing to ViaRE
+
+Thanks for reading this! That'd mean, hopefully, that you want to contribute
+with us.
+
+We try to make it possible that, by reading some of our code, you'll recognize
+our conventions and style.
+
+But if you're unsure about it, or you just want to know how we get things done,
+you should read this.
+
+## Contents
+
+- [**Git Flow**](#git-flow)
+    - [Commiting](#commiting)
+    - [Branching](#branching)
+- [**Code Style**](#code-style)
+- [**Versioning**](#versioning)
+- [**GitHub Related**](#github-related)
+    - [Issues](#issues)
+        - [Bugs](#bugs)
+        - [Enhancements](#enhancements)
+    - [Pull Requests](#pull-requests)
+- [**Thanks!**](#thanks)
+
+## Git Flow
+
+We use git —surprise!— to control versions. In this section, you can get to
+know our workflow in this, and all of our projects.
+
+### Commiting
+
+Commited changes should be small, avoiding big chunks of code being created,
+modified, or removed.
+
+Our commiting system is based on modularity. Each one should be able to be
+described in one sentence. If you need more than one, maybe you should make
+multiple commits.
+
+Yes, this can cause non—meaningful commits, but it makes easy to track down
+bugs and errors.
+
+If the change of the commit is style related, it doesn't matter the size of the
+modified code, as long as it doesn't change functionality.
+
+### Branching
+
+We try to follow the branching system published by [Vincent Driessen at nvie](https://nvie.com/posts/a-successful-git-branching-model/).
+
+`master` only has released versions. 
+
+`develop` is where all approved changes (that are not big enough to make it to
+a new version yet) go.
+
+From develop, we have multiple branches. Branches with meaningful names related
+to what is being developed inside each branch.
+
+A branch name must be short and descriptive, all lowercase. 
+Again, keep modularity in mind. For branches with multiple words `use-hyphens`.
+
+Once a new function or a bug-fix is implemented, we [create a Pull Request](#pull-requests)
+to merge changes back into `develop`.
+
+And once we feel that there are enough changes to make a new version of the
+project, we [create a Pull Request](#pull-requests) to merge changes into
+`master`.
+
+Each merge into `master` is tagged, meaning there's a new release. 
+See [Versioning](#versioning).
+
+## Code Style
+
+We try to be consistent with our style. When you doubt whether you should write
+`blah blah` or `yada yada`, follow the most important rule:
+**optimize for readabaility**.
+
+That said, these are our suggested rules
+
+- Indent using 4 spaces
+- Use spaces after commas (unless separated by newlines): `[1, 2, 3]`, `(a, b, c)`.
+- Use spaces after flow control statements: `if ()`, `for ()`, `while ()`
+- Use spaces around operators, except unaries: `x + y`, `x == y`, `x++`, `!x`.
+- Try to keep the line length at ~85. If exceeded, separate it in different lines.
+- `variable_names`, `CONSTANT_NAMES`, `Function_Names`, `StructureNames`
+- Write branch names in all lowercase, separeted with hyphens, and avoiding verbs: `graphics-simplification`, `docs`, `population-dynamics`
+- Insert new line before curly braces in blocks of code:
+
+```js
+
+// Do this
+if (condition)
+{
+
+}
+
+// Instead of this
+if (condition){
+
+}
+```
+
+- Always use curly braces after flow control statements. Even if it's followed
+by only one line:
+
+    ```js
+    // Do this
+    if (condition)
+    {
+        doSomethingInOneLine()
+    }
+
+    // Instead of this
+    if (condition)
+        doSomethingInOneLine()
+    ```
+
+## Versioning
+
+We follow [SemVer](https://semver.org/).
+
+Yup, just read it. Nothing to add.
+
+## GitHub Related
+
+### Issues
+
+If you have a question, don't open an issue. You can read the
+[FAQ](https://github.com/daque-dev/viare/blob/master/FAQ.md), or send us an e-mail
+at [contact@daque.me](mailto:contact@daque.me?Subject=Question)
+
+Issues are intended for reporting bugs, or discussing new features.
+
+Fortunately, GitHub allows us to provide an issue template. When you try to file
+a new issue, you'll see it. Try to fill it with all the info you can.
+
+Not all fields are required for every new issue. It depends on whether it is a bug
+report, or an enhancement discussion.
+
+#### Bugs
+
+The most important thing, is providing the necessary information to allow us to
+reproduce the problem. **Try to be as descriptive as possible.**
+
+Again, the best way to learn how to file an issue, is by taking a look at our
+[issue template](https://github.com/daque-dev/viare/issues/new).
+
+#### Enhancements
+
+This includes style changes, new features implementation, and general discussion
+on how to make ViaRE better. 
+
+We are more permissive on the structure of these issues. Anyways, you should still
+try to be as descriptive as possible.
+
+### Pull Requests
+
+Firs, you should read [Git Flow](#git-flow) and [Code Style](#code-style) sections.
+
+Once you have some changes that you'd like to see merged into our codebase, [open a
+Pull Request](https://github.com/daque-dev/viare/pull/new/master). We also have
+a PR template, that you'll see once you try to open one.
+
+Again, the most important thing is that you describe what changes you've made, and
+why you made them.
+
+---
+
+## Thanks!
+
+All that said, we will be very thankful and happy if you decide to contribute with
+the project.
+
+Don't be afraid to contribute if you feel you can't fulfil all of the rules in here.
+
+We will help you to help us.
+
+Cheers!

.github/ISSUE_TEMPLATE.md

@@ -1,33 +1,62 @@
-<!--- Provide a general summary of the issue in the Title above -->
+<!--- Provide a general summary of the issue in the title above -->
+
+<!-- This template has two forms: BUG or ENHANCEMENT. Fill appropiately -->
+<!-- and remove the other section of the form -->
+
+<!-------------------------------------------------------->
+<!----------------------- BUG FORM ----------------------->
+<!-------------------------------------------------------->
 
 ## Expected Behavior
-<!--- If you're describing a bug, tell us what should happen -->
-<!--- If you're suggesting a change/improvement, tell us how it should work -->
+<!-- What should happen in a healthy version of the project? -->
 
 ## Current Behavior
-<!--- If describing a bug, tell us what happens instead of the expected behavior -->
-<!--- If suggesting a change/improvement, explain the difference from current behavior -->
-
-## Possible Solution
-<!--- Not obligatory, but suggest a fix/reason for the bug, -->
-<!--- or ideas how to implement the addition or change -->
+<!-- What is happening, instead of what is expected? -->
 
-## Steps to Reproduce (for bugs)
+## Steps to Reproduce
 <!--- Provide a link to a live example, or an unambiguous set of steps to -->
 <!--- reproduce this bug. Include code to reproduce, if relevant -->
 1.
 2.
-3.
-4.
 
 ## Context
-<!--- How has this issue affected you? What are you trying to accomplish? -->
-<!--- Providing context helps us come up with a solution that is most useful in the real world -->
+<!-- How has this issue affected you? What are you trying to accomplish? -->
+<!-- Providing context helps us come up with a solution that is most useful in the real world -->
+<!-- Try to be as descriptive as possible. -->
 
 ## Your Environment
-<!--- Include as many relevant details about the environment you experienced the bug in -->
-* Version used:
-* Environment name and version (e.g. PHP 5.4 on nginx 1.9.1):
-* Server type and version:
-* Operating System and version:
-* Link to your project:
+<!-- Include as many relevant details about the environment -->
+<!-- you experienced the bug in. -->
+* ViaRE (release or commit): 
+* DMD:
+* SDL2:
+* SDL2_image:
+* OpenGL:
+* OS:
+
+## Possible Solution
+<!-- Not obligatory, but if you can, suggest a fix or explanation of why the bug happens -->
+
+<!---- Thank you for supporting us by reporting bugs! ---->
+<!---------------------- CHEERS! ------------------------->
+
+
+<!-------------------------------------------------------->
+<!------------------- ENHANCEMENT FORM ------------------->
+<!-------------------------------------------------------->
+
+## Suggested change
+<!-- What new feature would you like? -->
+<!-- What current feature would you like to be modified? -->
+<!-- What new feature would you like? -->
+
+## Context
+<!-- Why would that change make the project better? -->
+<!-- Providing context helps us come up with a solution that is most useful in the real world -->
+<!-- Try to be as descriptive as possible. -->
+
+## Possible Implementation Design
+<!-- Not obligatory, but if you can, suggest a proccess, abstraction, or explanation of how to get it done -->
+
+<!--- Thank you for supporting us by suggesting ideas! --->
+<!---------------------- CHEERS! ------------------------->

.github/PULL_REQUEST_TEMPLATE.md

@@ -3,14 +3,10 @@
 ## Description
 <!--- Describe your changes in detail -->
 
-## Related Issue
-<!--- This project only accepts pull requests related to open issues -->
-<!--- If suggesting a new feature or change, please discuss it in an issue first -->
-<!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
-<!--- Please link to the issue here: -->
-
 ## Motivation and Context
 <!--- Why is this change required? What problem does it solve? -->
+<!--- If it fixes an open issue, please link to the issue here. -->
+<!--- Protip: Just write #3 to reference to issue #3. GH knows. -->
 
 ## How Has This Been Tested?
 <!--- Please describe in detail how you tested your changes. -->