remove innecessary files and add .editorconfig + .github

Author: Gerard Casas Saez

.editorconfig

@@ -0,0 +1,37 @@
+# http://editorconfig.org
+
+root = true
+
+[*]
+indent_style = space
+indent_size = 4
+insert_final_newline = true
+trim_trailing_whitespace = true
+end_of_line = lf
+charset = utf-8
+
+# Docstrings and comments use max_line_length = 79
+[*.py]
+max_line_length = 119
+
+# Use 2 spaces for the HTML files
+[*.html]
+indent_size = 2
+
+# The JSON files contain newlines inconsistently
+[*.json]
+indent_size = 2
+insert_final_newline = ignore
+
+# Minified JavaScript files shouldn't be changed
+[**.min.js]
+indent_style = ignore
+insert_final_newline = ignore
+
+# Makefiles always use tabs for indentation
+[Makefile]
+indent_style = tab
+
+# Batch files use tabs for indentation
+[*.bat]
+indent_style = tab

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# 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, gender identity and expression, level of experience, 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 report@gerard.space. The project team will review and investigate all complaints, and will respond in a way that it deems 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 [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

.github/CONTRIBUTING.md

@@ -0,0 +1,58 @@
+# Contributing Guidelines
+
+Want to contribute to this repo? Great! We  :heart:  contributions. Just make sure to follow these guidelines.
+Read both the [general guidelines](#general-guidelines) and the [coding style guidelines](#coding-style-guidelines).
+By making a contribution, in any form (including, but not limited to, Issues and Pull Requests), you agree to abide by the [Code of Conduct](CODE_OF_CONDUCT.md).
+
+## How to contribute
+
+This platform is being used by several hackathons at the same time. To avoid conflicts between personalizations avoid editing constomizable fields like the stylesheet, hackathon_variables, form ordering or similar. Any Pull Request that could affect other hackathons will be deeply reviewed and could be rejected to avoid conflicts.
+
+## General Guidelines
+
+### New Feature or a Bug Fix?
+1. Fork the repo (you can ignore this step if you are a part of the maintainer team)
+2. Create a new branch with a descriptive name of the feature or the bug you are fixing.
+3. If you are a part of the maintainer team, push the branch to the remote so that others know that you are working on this branch. Otherwise, create a new issue mentioning that you would like to add a new feature or fix a bug you noticed. This lets us know that someone is already helping us fix the issue!
+4. Make changes and commit them. Your commit messages should be descriptive and imperative. Read [this](http://who-t.blogspot.com/2009/12/on-commit-messages.html) for guidelines.
+5. Create a pull request with a descriptive title. Clearly document any changes you made. You should be able to explain why you made those changes.
+6. Check Travis CI to see if there's any formatting errors and fix them
+
+### Working on the Next Release?
+1. Work on the `dev` or `develop` branch
+2. Create a pull request with a descriptive title. Clearly document any changes you made. You should be able to explain why you made those changes.
+
+## Coding Style Guidelines
+
+This project applies the same coding style than [Django Project](https://docs.djangoproject.com/en/1.11/internals/contributing/writing-code/coding-style/) which follows almost all [PEP-8](https://www.python.org/dev/peps/pep-0008/) coding guidelines.
+
+We allow up to 119 characters/line as this is the width of GitHub code review; anything longer requires horizontal scrolling which makes review more difficult. This check is included when you run flake8. Documentation, comments, and docstrings should be wrapped at 79 characters, even though PEP 8 suggests 72.
+
+All of this is enforced with Travis CI. All PRs will need to success on Travis before being merged.
+
+## Commit Message Guidelines
+
+Commit Guidelines inspired by [Gnome Commit Guidelines](https://wiki.gnome.org/Git/CommitMessages).
+
+Those are only general-purpose recommended guidelines, depending on the context of each PR the following rules can vary.
+
+Remember: the commit message is mainly for the other people, so they should be able to understand the changes made at any point in time.
+
+### Example
+
+```
+short explanation of the commit
+
+Longer (optional) explanation explaining exactly what's changed and why instead of how,
+whether any external or private interfaces changed, what bugs were fixed (with bug
+tracker reference if applicable) and so forth. Be concise but not too brief. Avoid writing long lines, use newlines when necessary.
+
+[Reference to the issue solved, if any]
+```
+
+### Details
+
+- First line (the brief description) must only be one sentence in imperative mood. The message should be concise, less than 50 characters if possible. Do not end it with a period.
+- The long explanation is optional, although it is encouraged to be written if it helps clarify the issue tackled. Explain the "why", not the "how" there and try to wrap every line at 72 characters. Also, keep a blank like between the first line and the long explanation.
+- Remember to commit your code with a [username](https://help.github.com/articles/setting-your-username-in-git/) and [email](https://help.github.com/articles/setting-your-email-in-git/).
+- If there is an issue created for this commit, link it at the end of the commit message, in a new line. The issue should follow the [GitHub guidelines](https://help.github.com/articles/closing-issues-via-commit-messages/#closing-an-issue-in-the-same-repository).

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,25 @@
+<!-- This form is for bug reports and feature requests-->
+
+## Is this a BUG REPORT or FEATURE REQUEST?
+
+
+
+## What happened
+(Include screenshots when possible)
+
+## What you expected to happen
+
+## How to reproduce it (as minimally and precisely as possible)
+
+
+## Anything else we need to know?
+
+## Environment
+- Browser version (Ex: Google Chrome 62.0.3202.94 (64-bit)...):
+- Domain: 
+- Others:
+
+(Optional)
+- Python version (`python --version`)
+- OS (e.g. from /etc/os-release):
+- Kernel (e.g. `uname -a`):

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,24 @@
+<!--  Thanks for sending a pull request!  Here are some tips for you:
+1. If this is your first time, read our contributor guidelines  https://github.com/HackAssistant/registration/blob/master/.github/CONTRIBUTING.md
+-->
+
+## What this PR does / Why we need it
+A few sentences describing the overall goals of the pull request's commits.
+
+## Which issue(s) this PR fixes (optional) 
+<!--Fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged)-->
+Fixes #
+
+## Special notes for your reviewer (optional)
+
+
+
+## Some questions
+- [ ] I have read the contributing guidelines
+- [ ] I abide by this repository Code of Conduct
+- [ ] I understand that my PR won't be merged until Travis gives a "green light"
+
+<!--You can leave this and check them once the PR has been created.-->
+
+## Additional Notes (optional)
+Do you want to add anything else? We :heart: to hear your opinions!

.gitignore

@@ -0,0 +1,6 @@
+.idea
+*.pyc
+__pycache__
+django_ha_hardware.egg-info
+dist/
+