Docs

.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 libdaque
+
+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/libdaque/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/libdaque/issues/new).
+
+#### Enhancements
+
+This includes style changes, new features implementation, and general discussion
+on how to make libdaque 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/libdaque/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

@@ -0,0 +1,59 @@
+<!--- 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
+<!-- What should happen in a healthy version of the project? -->
+
+## Current Behavior
+<!-- What is happening, instead of what is expected? -->
+
+## 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.
+
+## 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 -->
+<!-- Try to be as descriptive as possible. -->
+
+## Your Environment
+<!-- Include as many relevant details about the environment -->
+<!-- you experienced the bug in. -->
+* libdaque (release or commit): 
+* DMD:
+* 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

@@ -0,0 +1,32 @@
+<!--- Provide a general summary of your changes in the Title above -->
+
+## Description
+<!--- Describe your changes in detail -->
+
+## 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. -->
+<!--- Include details of your testing environment, and the tests you ran to -->
+<!--- see how your change affects other areas of the code, etc. -->
+
+## Screenshots (if appropriate):
+
+## Types of changes
+<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+
+## Checklist:
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
+- [ ] My code follows the code style of this project.
+- [ ] My change requires a change to the documentation.
+- [ ] I have updated the documentation accordingly.
+- [ ] I have read the **CONTRIBUTING** document.
+- [ ] I have added tests to cover my changes.
+- [ ] All new and existing tests passed.

CHANGELOG.md

@@ -0,0 +1,36 @@
+# Changelog
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
+and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
+
+<!-- ## [Unreleased]
+
+## [v0.3.0] - 2018-09-30
+### Added
+### Changed
+### Removed -->
+
+## [v0.2.2] - 2018-08-13
+### Added
+### Changed
+### Removed
+
+## [v0.2.1] - 2018-08-11
+### Added
+### Changed
+### Removed
+
+## [v0.2.0] - 2018-08-11
+### Added
+### Changed
+### Removed
+
+## v0.1.0 - 2018-08-11
+### Added
+
+[Unreleased]: https://github.com/daque-dev/libdaque/compare/v0.2.2...HEAD
+<!-- [v0.3.0]: https://github.com/daque-dev/libdaque/compare/v0.2.2...v0.3.0 -->
+[v0.2.2]: https://github.com/daque-dev/libdaque/compare/v0.2.1...v0.2.2
+[v0.2.1]: https://github.com/daque-dev/libdaque/compare/v0.2.0...v0.2.1
+[v0.2.0]: https://github.com/daque-dev/libdaque/compare/v0.1.0...v0.2.0

README.md

@@ -0,0 +1,14 @@
+# Daque Library
+
+Daque is development team formed in mid-2018. Its main project, [ViaRE] is a procedurally generated videogame focused in the simulation of human evolution and interaction.
+
+`libdaque` is the most important library used in [ViaRE],  and contains more useful modules to ease game development. It is highly mathematics-focused.
+
+`libdaque` handles graphic ports, mathematic operations for 3D visualization, and geometric and graphical utilities.
+
+Some extra functions in mind, but not ready at [current version] are approximation and interpolation of curves, mesh generation, thiessen polygons, morphology and hydrology simulations, population dynamics, social network theory, and many more things that could (and will) be used in [ViaRE].
+
+There's not 1.0.0 version yet.
+
+[current version]: https://github.com/daque-dev/libdaque/releases
+[ViaRE]: https://github.com/daque-dev/viare