Jingga/Organization-Guide
1
0
Fork 0
mirror of https://github.com/Karaka-Management/Organization-Guide.git synced 2026-01-11 21:08:41 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

change name

Browse Source
This commit is contained in:
Dennis Eichhorn 2022-04-21 19:55:00 +02:00
parent d0cef51b3c
commit 14c4b3d6bd
2 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Processes/Development.md
View File

@ -16,7 +16,7 @@ Generally, the development philosophy is result orientated. This means that anyo
Developers are encouraged to pick open tasks with high priorities according to their own skill level. Senior developers may directly assign tasks to developers based on their importance. New developers may find it easier to start with a task that has a low priority as they often also have a lower difficulty.
Open tasks can be found in the project overview: [PROJECT.md](https://github.com/Karaka-Management/Docs/blob/master/Project/PROJECT.md)
Open tasks can be found in the project overview: [PROJECT.md](https://github.com/Karaka-Management/Organization-Guide/blob/master/Project/PROJECT.md)
Tasks currently in development are prefixed in the priority column with an asterisk `*` and a name tag in the task description of the developer who is working on the task.
@ -26,7 +26,7 @@ The open tasks are reviewed once a month by a senior developer. The senior dev
Code changes must follow the [style guidelines](https://github.com/Karaka-Management/Developer-Guide/tree/develop/standards). Additionally, the automatic code style inspection tools must return no errors, failures or warnings. Developers should test their changes with inspection tools and configurations mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md) in advance before submitting them for review.
In rare cases errors, failures or warnings during the automatic inspection are acceptable. Reasons can be changes in the programming language, special cases which cannot, are difficult or must be individually configured in the inspection settings. If this is the case for a code change and if inspection configuration changes are necessary are decided by the senior developer performing the code review.
In rare cases errors, failures or warnings during the automatic inspection are acceptable. Reasons can be changes in the programming language, special cases which cannot, are difficult or must be individually configured in the inspection settings. If this is the case for a code change and if inspection configuration changes are necessary are decided by the senior developer performing the code review.
Automated checks which are run during the review process:
@ -37,7 +37,7 @@ npx eslint ./ -c ./Build/Config/.eslintrc.json
### Tests
Code changes must follow the inspection guidelines (i.e. code coverage) mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md). Developers should check if the code changes comply with the inspection guidelines before submitting them.
Code changes must follow the inspection guidelines (i.e. code coverage) mentioned in the [inspection documentation](https://github.com/Karaka-Management/Developer-Guide/blob/develop/quality/inspections.md). Developers should check if the code changes comply with the inspection guidelines before submitting them.
In rare cases it might be not possible to follow the inspection guidelines. In such cases the senior developer performing the code review may decide if the code change still gets accepted.
@ -54,11 +54,11 @@ Additional inspections which are run but might be ignored during the review depe
### Demo
Some code changes may also require changes or extensions in the demo setup scripts. The demo setup script try to simulate a real world use case by generating and modifying mostly random data. This is also a good way to setup and “manually” test the code changes in a larger picture. The demo setup script can be found in the [demoSetup](https://github.com/Karaka-Management/demoSetup) repository. The demo setup script takes a long time due to the large amount of user input simulated data which is generated. Therefore it is recommended to run this only sporadically.
Some code changes may also require changes or extensions in the demo setup scripts. The demo setup script try to simulate a real world use case by generating and modifying mostly random data. This is also a good way to setup and “manually” test the code changes in a larger picture. The demo setup script can be found in the [demoSetup](https://github.com/Karaka-Management/demoSetup) repository. The demo setup script takes a long time due to the large amount of user input simulated data which is generated. Therefore it is recommended to run this only sporadically.
### Code review
In addition to the automatic code review performed by the various inspection tools such as (phpcs, phpstan, phpunit, eslint and custom scripts) a senior developer must check the proposed code change before it is merged with the respective `develop` branch. Only upon the approval by the reviewer a code change requests gets merged as no other developers have permission in the software to make such code merges.
In addition to the automatic code review performed by the various inspection tools such as (phpcs, phpstan, phpunit, eslint and custom scripts) a senior developer must check the proposed code change before it is merged with the respective `develop` branch. Only upon the approval by the reviewer a code change requests gets merged as no other developers have permission in the software to make such code merges.
In case a code change request is not approved the reviewer states the reason for the decision, this may include some tips and requests which will allow the contributor to make improvements so that the code change may get approved.

6
README.md
View File

@ -51,7 +51,7 @@ Currently Karaka is still developing the first Alpha version. As soon as we have
General updates can be found in our info section at https://karaka.app/info and developer updates can be found in our developer section at https://karaka.app/dev. In our developer section you can also check out the automatically generated reports such as code coverage, code style, static analysis etc. as well as our code style guide lines and developer documentation.
* [Project Status](https://github.com/Karaka-Management/Docs/blob/master/Project/PROJECT.md)
* [Project Status](https://github.com/Karaka-Management/Organization-Guide/blob/master/Project/PROJECT.md)
## Tech stack
@ -62,13 +62,13 @@ General updates can be found in our info section at https://karaka.app/info and
## Become a contributor
Karaka has a very open culture and we always welcome new people who share our philosophy in providing create solutions which just work. You can find the development process description which also describes how to become a contributer in the [Project Documentation](https://github.com/Karaka-Management/Docs/blob/master/Processes/Development.md).
Karaka has a very open culture and we always welcome new people who share our philosophy in providing create solutions which just work. You can find the development process description which also describes how to become a contributer in the [Project Documentation](https://github.com/Karaka-Management/Organization-Guide/blob/master/Processes/Development.md).
## Misc
* End-User documentation: https://github.com/Karaka-Management/Documentation
* Developer documentation: https://github.com/Karaka-Management/Developer-Guide
* Project documentation: https://github.com/Karaka-Management/Docs
* Project documentation: https://github.com/Karaka-Management/Organization-Guide
* Website: [https://karaka.app](https://karaka.app)
* Demo: [https://karaka.app](https://karaka.app) (user: admin, pass: orange)
* Dev: [https://karaka.app/dev](https://karaka.app/dev)