Merge pull request #124 from alliander-opensource/feature/open-doc-update

update open source documentation

Author: TonyXiang8787

CONTRIBUTING.md

@@ -15,7 +15,7 @@ There are just a few small guidelines you need to follow before making a change.
 Contribution does not necessarily mean committing code to the repository. 
 We recognize different levels of contributions as shown below in increasing order of dedication:
 
-1. Test and use the libray. Give feedback on the user experience or suggest new features.
+1. Test and use the library. Give feedback on the user experience or suggest new features.
 2. Validate the model against other existing libraries. Provide validation test cases.
 3. Report bugs.
 4. Improve the Python interface or helper functions.
@@ -90,7 +90,7 @@ git commit ... --no-verify
 
 All the files in the repository need to be [REUSE compliant](https://reuse.software/). 
 We use the pipeline to automatically check this.
-If there are files which are not complying, the pipeline will fail the pull request will be blocked.
+If there are files which are not complying, the pipeline will fail and the pull request will be blocked.
 
 
 ## Git branching
@@ -126,7 +126,7 @@ There are other great tools out there to manage DCO signoffs for developers to m
 * Git makes it easy to add this line to your commit messages. Make sure the `user.name` and `user.email` are set in your git configs. Use `-s` or `--signoff` to add the Signed-off-by line to the end of the commit message.
 * [Github UI automatic signoff capabilities](https://github.blog/changelog/2022-06-08-admins-can-require-sign-off-on-web-based-commits/) for adding the signoff automatically to commits made with the GitHub browser UI. This one can only be activated by the github org or repo admin. 
 * [GitHub UI automatic signoff capabilities via custom plugin]( https://github.com/scottrigby/dco-gh-ui ) for adding the signoff automatically to commits made with the GitHub browser UI
-* Additionally, it is possible to use shell scripting to automatically apply the sign-off. For an example for bash to be put into a .bashrc file, see [here](https://wiki.lfenergy.org/display/HOME/Contribution+and+Compliance+Guidelines+for+LF+Energy+Foundation+hosted+projects). 
+* Additionally, it is possible to use shell scripting to automatically apply the sign-off. For an example for bash to be put into a .bashrc file, see [here](https://wiki.lfenergy.org/display/HOME/Contribution+and+Compliance+Guidelines). 
 * Alternatively, you can add `prepare-commit-msg hook` in .git/hooks directory. For an example, see [here](https://github.com/Samsung/ONE-vscode/wiki/ONE-vscode-Developer's-Certificate-of-Origin).
 
 ## Code reviews
@@ -143,7 +143,7 @@ Contributions should be submitted as Github pull requests. See [Creating a pull
 The process for a code change and pull request you should follow:
 
 1. Create a topic branch in your local repository, following the naming format
-"feature-###" or "fix-###". For more information see the Git branching guideline.
+"feature/###" or "fix/###". For more information see the Git branching guideline.
 1. Make changes, compile, and test thoroughly. Ensure any install or build dependencies are removed before the end of the layer when doing a build. Code style should match existing style and conventions, and changes should be focused on the topic the pull request will be addressed. For more information see the style guide.
 1. Push commits to your fork.
 1. Create a Github pull request from your topic branch.

README.md

@@ -164,9 +164,24 @@ Node Result
 1   2          1  0.994801  10445.415523 -0.003096
 ```
 
+# Folder Structure
+
+The repository folder structure is as follows. The `examples`, `docs` and `scripts` are self-explanatory.
+
+- The C++ calculation core is inside [include/power-grid-model](include/power-grid-model).
+- The python interface code is in [src/power_grid_model](src/power_grid_model)
+- The code for validation of input data is in [validation](src/power_grid_model/validation) folder.
+- The [tests](tests) folder is divided in the following way:
+  - `cpp_unit_tests` contains the tests for the C++ calculation core.
+  - `benchmark_cpp` contains a benchmark test case generator in C++.
+  - `unit` folder contains tests for the python code.
+  - `data` contains validation test cases designed for every component and algorithm. Some sample network types are also included. 
+  The validation is either against popular power system analysis software or hand calculation.
+
 # Examples
 
-Please refer to [Examples](examples) for more detailed examples for power flow and state estimation.
+Please refer to [Examples](examples) for more detailed examples for power flow and state estimation. 
+Notebooks for validating the input data and exporting input/output data are also included.
 
 # License
 This project is licensed under the Mozilla Public License, version 2.0 - see [LICENSE](LICENSE) for details.

RELEASE.md

@@ -10,12 +10,12 @@ This project uses a rolling release strategy on `main` branch.
 A new push(merge) to the `main` branch will trigger GitHub Actions to automatically 
 build and upload a new version to PyPI with a unique version number.
 
-**All the bug fixes will be commited directly into the `main` branch and published in the latest release. 
+**All the bug fixes will be committed directly into the `main` branch and published in the latest release. 
 No effort will be spent on backporting bug fixes to previous versions!**
 
 Sometimes a `release/` branch will be created temporarily for 
 a big new version with new features and/or breaking changes.
 A push(merge) to the release branch will tigger GitHub Actions to automatically 
 build and upload a new version to PyPI with a unique release-candidate version number (suffix `rc`).
 
-**NOTE: Release candicate versions are for testing only. You should not use them in production!**
+**NOTE: Release candidate versions are for testing only. You should not use them in production!**