refactor(/docs): rework documentation structure layout (#179)

* refactor(/docs): rework documentation structure layout

* refactor(/docs): update file reference paths

* feat(/docs): add English version of other-proxy-protocol.md

* refacotr: move docs/templates/ docs/sync/ to hack/

* fix(example.dae|readme): update ref link to adopt new file structure

* refactor: rename other-proxy-protocol.md -> proxy-protocols.md

* docs(readme): add ref to proxy-protocols.md

* feat(/docs): add English version of how-it-works.md

* refactor: rename how-it-works; add nav links

* fix: fix linting errors

* fix: fix linting errors

---------

Co-authored-by: earrmouth <43926351+earrmouth@users.noreply.github.com>

docs/en/development/commit-msg-guide.md

@@ -0,0 +1,81 @@
+# Semantic Commit Messages
+
+## The reasons for these conventions
+
+- automatic generating of the changelog
+- simple navigation through Git history (e.g. ignoring the style changes)
+
+See how a minor change to your commit message style can make you a better developer.
+
+## Format
+
+```
+`<type>(<scope>): <subject>`
+
+`<scope>` is optional
+```
+
+## Example
+
+```
+feat: add hat wobble
+^--^  ^------------^
+|     |
+|     +-> Summary in present tense.
+|
++-------> Type: chore, docs, feat, fix, refactor, style, or test.
+```
+
+Example `<type>` values:
+
+- `feat`: (new feature for the user, not a new feature for build script)
+- `fix`: (bug fix for the user, not a fix to a build script)
+- `docs`: (changes to the documentation)
+- `style`: (formatting, missing semi colons, etc; no production code change)
+- `refactor`: (refactoring production code, eg. renaming a variable)
+- `test`: (adding missing tests, refactoring tests; no production code change)
+- `chore`: (updating grunt tasks etc; no production code change, e.g. dependencies upgrade)
+- `perf`: (perfomance improvement change, e.g. better concurrency performance)
+- `ci`: (updating CI configuration files and scripts e.g. `.gitHub/workflows/*.yml` )
+
+Example `<Scope>` values:
+
+- `init`
+- `runner`
+- `watcher`
+- `config`
+- `web-server`
+- `proxy`
+
+The `<scope>` can be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted. In smaller projects such as Karma plugins, the `<scope>` is empty.
+
+## Message Subject (First Line)
+
+The first line cannot be longer than `72` characters and should be followed by a blank line. The type and scope should always be lowercase as shown below
+
+## Message Body
+
+use as in the `<subject>`, use the imperative, present tense: "change" not "changed" nor "changes". Message body should include motivation for the change and contrasts with previous behavior.
+
+## Message footer
+
+### Referencing issues
+
+Closed issues should be listed on a separate line in the footer prefixed with "Closes" keyword as the following:
+
+```
+Closes #234
+```
+
+or in the case of multiple issues:
+
+```
+Closes #123, #245, #992
+```
+
+## References
+
+- <https://www.conventionalcommits.org/>
+- <https://seesparkbox.com/foundry/semantic_commit_messages>
+- <http://karma-runner.github.io/1.0/dev/git-commit-msg.html>
+- <https://wadehuanglearning.blogspot.com/2019/05/commit-commit-commit-why-what-commit.html>

docs/en/development/contribute.md

@@ -0,0 +1,50 @@
+# Contribute
+
+If you want to contribute to a project and make it better, your help is very welcome. Contributing is also a great way to learn more about social coding on GitHub, new technologies and their ecosystems and how to make constructive, helpful bug reports, feature requests and the noblest of all contributions: a good, clean pull request.
+
+## Bug Reports and Feature Requests
+
+If you have found a `bug` or have a `feature request`, please use the search first in case a similar issue already exists. If not, please create an [issue](https://github.com/daeuniverse/dae/issues/new) in this repository
+
+## Code
+
+If you would like to fix a bug or implement a feature, please `fork` the repository and `create a Pull Request`.
+
+Before you start any Pull Request, `it is recommended that you create an issue` to discuss first if you have any doubts about requirement or implementation. That way you can be sure that the maintainer(s) agree on what to change and how, and you can hopefully get a quick merge afterwards.
+
+`Pull Requests` can only be merged once all status checks are green.
+
+## Pre-commit Hook
+
+This repo uses [pre-commit hook](https://github.com/pre-commit/pre-commit-hooks) to apply linting check prior to writing commit to local Git history. To set up pre-commit, do the followings:
+
+```bash
+# install pre-commit
+pip3 install pre-commit
+# install pre-commit hooks
+pre-commit install
+```
+
+## How to make a clean pull request
+
+- Create a `personal fork` of the project on GitHub.
+- Clone the fork on your local machine. Your remote repo on GitHub is called `origin`.
+- Add the original repository as a remote called `upstream`.
+- If you created your fork a while ago be sure to pull upstream changes into your local repository.
+- Create a new branch to work on! Branch from `develop` if it exists, else from `master`.
+- Implement/fix your feature, comment your code.
+- Follow the code style of the project, including indentation.
+- If the project has tests run them!
+- Write or adapt tests as needed.
+- Add or change the documentation as needed.
+- Squash your commits into a single commit with Git's [interactive rebase](https://help.github.com/articles/interactive-rebase). Create a new branch if necessary.
+- Push your branch to your fork on GitHub, the remote `origin`.
+- From your fork open a pull request in the correct branch. Target the project's `develop` branch if there is one, else go for `master`!
+- Once the pull request is approved and merged you can pull the changes from `upstream` to your local repo and delete
+  your extra branch(es).
+
+And last but not least: Always write your commit messages in the present tense. Your commit message should describe what the commit, when applied, does to the code – not what you did to the code.
+
+## Re-requesting a review
+
+Please do not ping your reviewer(s) by mentioning them in a new comment. Instead, use the re-request review functionality. Read more about this in the [GitHub docs, Re-requesting a review](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request#re-requesting-a-review).