feat(docs): README update (#139)

* README update

* feat(docs): fixed README and command list generation

* feat(docs): fixed docs/commands/README.md

* fix

* guidelines fix

* added the things from the call with Berhnard

* some minor readme adjustments

---------

Co-authored-by: Artsiom Shamsutdzinau <[email protected]>
Co-authored-by: Fedor Kurbatov <[email protected]>

CONTRIBUTING.md

@@ -0,0 +1,25 @@
+## Contribute Code
+
+You are welcome to contribute to Fluence!
+
+Things you need to know:
+
+1.  You need to **agree to the [Contributor License Agreement](https://gist.github.com/fluencelabs-org/3f4cbb3cc14c1c0fb9ad99d8f7316ed7) (CLA)**. This is a common practice in all major Open Source projects. At the current moment, we are unable to accept contributions made on behalf of a company. Only individual contributions will be accepted.
+
+2.  **Not all proposed contributions can be accepted**. Some features may, e.g., just fit a third-party add-on better. The contribution must fit the overall direction of Fluence and really improve it. The more effort you invest, the better you should clarify in advance whether the contribution fits: the best way would be to just open an issue to discuss the contribution you plan to make.
+
+### Contributor License Agreement
+
+When you contribute, you have to be aware that your contribution is covered by **[Apache License 2.0](./LICENSE)**, but might relicensed under few other software licenses mentioned in the **Contributor License Agreement**.  In particular, you need to agree to the Contributor License Agreement. If you agree to its content, you simply have to click on the link posted by the CLA assistant as a comment to the pull request. Click it to check the CLA, then accept it on the following screen if you agree to it. The CLA assistant will save this decision for upcoming contributions and will notify you if there is any change to the CLA in the meantime.
+
+## Technical guidelines
+
+- To use fluence-cli in the development mode, run: `./bin/dev.js` (types are not checked in development mode because it's faster and more convenient to work with. Use typechecking provided by your IDE during development)
+- To use fluence-cli in the production mode, run `npm run build` first, then run: `./bin/run.js`. If you want to make sure you are running the actual package the users will use, do `npm run build`, `npm pack` and install this tar package (the approach is used for tests)
+- Don't name arguments or flags with names that contain underscore symbols because autogenerated links in markdown will not work
+- pre-commit runs each time before you commit. It attempts to build and lint your project, runs prettier and generates this README.md file that you are reading right now. 
+- If you are using nvm and want to commit using VSCode, place `.huskyrc` file to your home directory
+- Don't export anything from command files except for the command itself. If you need to share code between commands - create a separate file
+- Avoid using `this` in commands except for inside `initCli` function. This style is easier to understand and there will be less stuff to refactor if instead of using methods on command object you simply use separate functions which can later be moved outside into a separate module for reuse in other commands
+- Use `commandObj.error` for human readable errors. They will be reported to analytics as events. Use `throw new Error` (or `assert`) for unexpected errors. They will be reported to analytics as crashes.
+- Don't use colors inside commands descriptions. They can't be rendered to markdown and they will not be rendered to users of the packaged fluence-cli anyway, when they run `--help`

LICENSE

@@ -1,4 +1,3 @@
-
                                  Apache License
                            Version 2.0, January 2004
                         http://www.apache.org/licenses/