feat(): open-source documentation

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,26 @@
+---
+name: Bug report
+about: Tell us what is broken
+
+---
+
+### Description
+Describe your issue here.
+
+### Environment
+- version of CRviz?
+- which browser and its version?
+- versions of the following (if known and/or applicable)
+  - node.js
+  - RxJS
+  - D3
+  - Docker
+
+### Steps to reproduce
+Tell us how to recreate your issue.
+
+### Expected results
+What did you think would happen?
+
+### Actual results
+What **really** happened?

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,17 @@
+---
+name: Feature request
+about: Tell us what you think needs improvement
+
+---
+
+### Describe the feature you are requesting
+A clear and concise description of the functionality you would like implemented.
+
+### Describe your use case
+A clear and concise explanation of the obstacle you are facing.  
+
+### Explain how this feature supports your use case? Other use cases?
+Why should this be implemented in the way you are suggesting?
+
+### Additional Info
+Add any other information relevant to this request

AUTHORS

@@ -0,0 +1,7 @@
+# This file lists all individuals having contributed design, concept, and
+# content to the repository.
+#
+# For a list of active project maintainers, see the MAINTAINERS file.
+#
+Hope Tambala<hope@puente-dr.com>
+

CONTRIBUTING.md

@@ -0,0 +1,94 @@
+# Contributing to Puente Dashboard
+
+Do you want to help us make awesome open-source software for humanitarian work?
+
+Awesome! Here are instructions to get you started.
+
+## Contribution guidelines
+
+### Pull requests are always welcome
+
+We are always thrilled to receive pull requests, and do our best to
+process them as fast as possible. Not sure if that typo is worth a pull
+request? Do it! We will appreciate it.
+
+If your pull request is not accepted on the first try, don't be
+discouraged! If there's a problem with the implementation, hopefully you
+received feedback on what to improve.
+
+### Create issues...
+
+Any significant improvement should be documented as [a github
+issue](https://github.com/hopetambala/puente-react-dashboard/issues) before anybody
+starts working on it.
+
+### ...but check for existing issues first!
+
+Please take a moment to check that an issue doesn't already exist
+documenting your bug report or improvement proposal. If it does, it
+never hurts to add a quick "+1" or "I have this problem too". This will
+help prioritize the most common problems and requests.
+
+### Conventions
+
+Fork the repo and make changes on your fork in a feature branch.
+
+Make sure you include relevant updates or additions to documentation and
+tests when creating or modifying features.
+
+Pull requests descriptions should be as clear as possible and include a
+reference to all the issues that they address.
+
+Code review comments may be added to your pull request. Discuss, then make the
+suggested modifications and push additional commits to your feature branch. Be
+sure to post a comment after pushing. The new commits will show up in the pull
+request automatically, but the reviewers will not be notified unless you
+comment.
+
+Before the pull request is merged, make sure that you squash your commits into
+logical units of work using `git rebase -i` and `git push -f`. After every
+commit the test suite should be passing. Include documentation changes in the
+same commit so that a revert would remove all traces of the feature or fix.
+
+Commits that fix or close an issue should include a reference like `Closes #XXX`
+or `Fixes #XXX`, which will automatically close the issue when merged.
+
+Add your name to the AUTHORS file, but make sure the list is sorted and your
+name and email address match your git configuration. The AUTHORS file is
+regenerated occasionally from the git commit history, so a mismatch may result
+in your changes being overwritten.
+
+## Decision process
+
+### How are decisions made?
+
+Short answer: with pull requests to the CRviz repository.
+
+All decisions affecting Puente-React-Dashboard follow the same 3 steps:
+
+* Step 1: Open a pull request. Anyone can do this.
+
+* Step 2: Discuss the pull request. Anyone can do this.
+
+* Step 3: Accept or refuse a pull request. A maintainer does this.
+
+
+### How can I become a maintainer?
+
+* Step 1: learn the code inside out
+* Step 2: make yourself useful by contributing code, bugfixes, support etc.
+
+Don't forget: being a maintainer is a time investment. Make sure you will have time to make yourself available.
+You don't have to be a maintainer to make a difference on our project!
+
+### What are a maintainer's responsibility?
+
+It is every maintainer's responsibility to:
+
+* 1) Deliver prompt feedback and decisions on pull requests.
+* 2) Be available to anyone with questions, bug reports, criticism etc. on CRviz.
+
+### How is this process changed?
+
+Just like everything else: by making a pull request :D
+

MAINTAINERS

@@ -0,0 +1 @@
+hopetambala   <hopetambala@outlook.com>

PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,11 @@
+### Description of proposed changes
+What does this pull request accomplish? Why should it be integrated?
+
+### Checklist
+_Put an `x` in the boxes that apply. _
+- [ ] My lint and unit tests pass locally with my changes
+- [ ] I have added tests that prove my changes work (if applicable)
+- [ ] I have added or updated necessary documentation (if appropriate)
+
+### Additional comments
+Is there anything else you want me to know?