docs: adds contributor related docs and github templates

.distignore

@@ -2,33 +2,29 @@
 .distignore
 .gitignore
 .travis.yml
-.jshintrc
+.stylelintrc
+docker-compose.yml
 Gruntfile.js
-code_quality
-grunt
+webpack.config.js
+CONTRIBUTING.md
+CODE_OF_CONDUCT.md
 phpcs.xml
-node_modules
-logs
+phpunit.xml
+phpunit-cc.xml
+phpmd.xml
 package.json
 package-lock.json
+composer.json
+composer.lock
+npm-debug.log
 bin
-Dockerfile
-.env
-vue_src
+node_modules
+logs
+grunt
 tests
-phpunit.xml
-phpunit-cc.xml
-npm-debug.log
 dist
+build
 artifact
-composer.json
-composer.lock
-key.enc
-languages
-.stylelintrc
-init.sh
-docker-compose.yml
-package-lock.json
-phpmd.xml
-webpack.config.js
-assets/vue
+assets/vue
+.wporg
+.github

.github/ISSUE_TEMPLATE/Bug_report.md

@@ -0,0 +1,34 @@
+---
+name: "Bug report"
+about: Report a bug if something isn't working as expected in the Optimole
+  plugin.
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Isolating the problem (mark completed items with an [x]):**
+- [ ] I have deactivated other plugins and confirmed this bug occurs when only Optimole plugin is active.
+- [ ] This bug happens with a default WordPress theme active
+- [ ] I can reproduce this bug consistently using the steps above.
+
+**WordPress Environment**
+<details>
+ WordPress Version:
+ Optimole Version: 
+ PHP versions: 
+</details>

.github/ISSUE_TEMPLATE/Feature_request.md

@@ -0,0 +1,17 @@
+---
+name: "Feature request"
+about: "Suggest a new feature We'll consider building it in the next releases"
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is.
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,25 @@
+### All Submissions:
+
+* [ ] Have you followed the [Optimole Contributing guideline](https://github.com/Codeinwp/optimole-wp/blob/master/CONTRIBUTING.md)?
+* [ ] Does your code follow the [WordPress' coding standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/)?
+* [ ] Have you checked to ensure there aren't other open [Pull Requests](../../pulls) for the same update/change? 
+
+
+### Changes proposed in this Pull Request:
+
+
+
+Closes # .
+
+### How to test the changes in this Pull Request:
+
+1.
+2.
+3.
+
+### Other information:
+
+* [ ] Have you added an explanation of what your changes do and why you'd like us to include them?
+* [ ] Have you written new tests for your changes, as applicable?
+* [ ] Have you successfully ran tests with your changes locally?
+

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 email 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 friends@optimole.com. 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/

CONTRIBUTING.md

@@ -0,0 +1,180 @@
+# Contributing to Optimole ⚙
+
+We would love for you to contribute to Optimole and help make it even better than it is
+today! As a contributor, here are the guidelines we would like you to follow:
+
+ - [Code of Conduct](#coc)
+ - [Question or Problem?](#question)
+ - [Issues and Bugs](#issue)
+ - [Feature Requests](#feature)
+ - [Submission Guidelines](#submit)
+ - [Coding Guidelines](#rules)
+ - [Commit Message Guidelines](#commit) 
+
+## <a name="coc"></a> Code of Conduct
+Help us keep Optimole open and inclusive. Please read and follow our [Code of Conduct][coc].
+
+## <a name="question"></a> Got a Question or Problem?
+
+Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests. You've got much better chances of getting your question answered if you contact us directly on [optimole.com](https://optimole.com)
+
+To save your and our time, we will systematically close all issues that are requests for general support and redirect people to our support form.
+
+## <a name="issue"></a> Found a Bug?
+If you find a bug in the source code, you can help us by
+[submitting an issue](#submit-issue) to our [GitHub Repository][github]. Even better, you can
+[submit a Pull Request](#submit-pr) with a fix.
+
+## <a name="feature"></a> Missing a Feature?
+You can *request* a new feature by [submitting an issue](#submit-issue) to our GitHub
+Repository. If you would like to *implement* a new feature, please submit an issue with
+a proposal for your work first, to be sure that we can use it.
+Please consider what kind of change it is:
+
+* For a **Major Feature**, first open an issue and outline your proposal so that it can be
+discussed. This will also allow us to better coordinate our efforts, prevent duplication of work,
+and help you to craft the change so that it is successfully accepted into the project.
+* **Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
+
+## <a name="submit"></a> Submission Guidelines
+
+### <a name="submit-issue"></a> Submitting an Issue
+
+Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
+
+We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it.  
+
+A minimal reproduction allows us to quickly confirm a bug (or point out a coding problem) as well as confirm that we are fixing the right problem.
+
+Unfortunately, we are not able to investigate / fix bugs without a minimal reproduction, so if we don't hear back from you we are going to close an issue that doesn't have enough info to be reproduced.
+
+You can file new issues by selecting from our [new issue templates](https://github.com/Codeinwp/optimole-wp/issues/new/choose) and filling out the issue template.
+
+
+### <a name="submit-pr"></a> Submitting a Pull Request (PR)
+Before you submit your Pull Request (PR) consider the following guidelines:
+
+1. Search [GitHub](https://github.com/Codeinwp/optimole-wp/pulls) for an open or closed PR
+  that relates to your submission. You don't want to duplicate effort.
+1. Be sure that an issue describes the problem you're fixing, or documents the design for the feature you'd like to add.
+  Discussing the design up front helps to ensure that we're ready to accept your work. 
+1. Fork the Codeinwp/optimole-wp repo.
+1. Make your changes in a new git branch:
+
+     ```shell
+     git checkout -b my-fix-branch master
+     ```
+
+1. Create your patch, **including appropriate test cases**. 
+1. If you are familiar with Docker, you can test your change in a containerezed environment by running `docker-compose up -d`. The environment will contains wordpress files + npm and phpunit used in the testing routines. More details about the docker image used [here](https://github.com/HardeepAsrani/pirate-brewery) 
+1. Follow the [WordPress Coding Standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/) and make sure the changes are following the standard using `composer run-script lint` command.
+1. Run the full PHPUnit test suite, using `composer run-script test` command, and ensure that all tests pass.
+1. Commit your changes using a descriptive commit message that follows our
+  [commit message conventions](#commit). Adherence to these conventions
+  is necessary because release notes are automatically generated from these messages.
+1. Push your branch to GitHub:
+
+    ```shell
+    git push origin my-fix-branch
+    ```
+
+1. In GitHub, send a pull request to `optimole-wp:master`.
+* If we suggest changes then:
+  * Make the required updates.
+  * Re-run the PHPunit test suites to ensure tests are still passing and coding standard is followed.
+  * Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
+
+    ```shell
+    git rebase master -i
+    git push -f
+    ```
+
+That's it! Thank you for your contribution!
+
+## <a name="rules"></a> Coding Guidelines 
+
+- **Ensure you stick to the [WordPress Coding Standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/)**
+- Install our pre-commit hook using npm. It'll help with the Coding Standards. To install run `npm install` from the command line within the optimole-wp plugin directory.
+- Ensure you use LF line endings in your code editor. Use [EditorConfig](http://editorconfig.org/) if your editor supports it so that indentation, line endings and other settings are auto configured.
+- When committing, reference your issue number (#1234) and follow the [commit message conventions](#commit) .
+- Ensure that your code is compatible with PHP 5.4+.
+- Push the changes to your fork and submit a pull request on the master branch of the `optimole-wp` repository.
+
+## <a name="commit"></a> Commit Message Guidelines
+
+We have very precise rules over how our git commit messages can be formatted.  This leads to **more
+readable messages** that are easy to follow when looking through the **project history**.  But also,
+we use the git commit messages to **generate the Optimole Changelog**.
+
+### Commit Message Format
+Each commit message consists of a **header**, a **body** and a **footer**.  The header has a special
+format that includes a **type**, a **scope** and a **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+The **header** is mandatory and the **scope** of the header is optional.
+
+Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
+to read on GitHub as well as in various git tools.
+
+The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
+
+```
+fix(rest): adds missing parameter in the authentication REST request
+```
+```
+fix(settings): improve validation of the height control
+
+The height control was allowing null values to be saved.
+```
+
+### Type
+Must be one of the following:
+
+* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+* **docs**: Documentation only changes
+* **feat**: A new feature
+* **fix**: A bug fix
+* **perf**: A code change that improves performance
+* **refactor**: A code change that neither fixes a bug nor adds a feature
+* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+* **test**: Adding missing tests or correcting existing tests
+
+### Scope
+The scope should be the name of the npm package affected (as perceived by the person reading the changelog generated from commit messages.
+
+The following is the list of supported scopes:
+
+* **settings**
+* **api**
+* **rest**
+* **ui**
+* **admin**
+* **cron**
+* **replacer**
+* **lazyload**
+
+### Subject
+The subject contains a succinct description of the change:
+
+* use the imperative, present tense: "change" not "changed" nor "changes"
+* don't capitalize the first letter
+* no dot (.) at the end
+
+### 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.
+
+### Footer
+The footer should contain any information about **Breaking Changes** and is also the place to
+reference GitHub issues that this commit **Closes**.
+
+**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
+ 

composer.json

@@ -30,6 +30,7 @@
     "format": "phpcbf --standard=phpcs.xml --report-summary --report-source",
     "phpcs": "phpcs --standard=phpcs.xml",
     "phpmd": "phpmd inc text phpmd.xml",
+    "test": "phpunit --confirguration=phpunit.xml",
     "lint": "composer run-script phpcs"
   },
   "require": {

themeisle-hash.json

@@ -1 +1 @@
-{"optimole-wp.php":"070ad3c67447560927b404875a654321"}
+{"optimole-wp.php":"ce09c6876abe82196778fdde7d3bd316"}