Pull Request Guideline

Don't work on upstream master branch.
Treat your personal upstream branch as base for development.
Avoid direct committing to any branch in this repository except you personal branch.
Periodically sync your personal branch with master branch (you can directly push such commits).
Use dedicated branches in your forks for development - try to keep master and your personal branch intact and synced with upstream repository.
All solutions should be submitted via a pull request.

Create PRs from development branches in your forks to your personal branch in this repository.
Try to give descriptive title to PR.
Treat first message of PR discussion as PR description (you can edit it afterwards) and provide explanation of the work.
Apply appropriate label to your PRs to reflect its readiness for review.
Use @mentions to ping others if you need some reaction.
PR updating:
- In general a pull request is updated through overwriting the existing branch with changed or newly added commits.
- Don't forget to describe changes by message in PR conversation.

Keep sources in dedicated subdirectories under appropriate lesson or practice topic.
Source code should be formatted according to kernel coding standards.
Try to use meaningful names for modules, their API, source files and in code.
Kernel modules should include MODULE_AUTHOR and MODULE_DESCRIPTION.

Commit messages should include:
- subject line (started from [tags]);
- descriptive body, separated by empty line;
- Signed-off-by line (use -s option to git commit)
If new exercise, you provide solution for, is based on another exercise or third-party code, you should commit a clean copy first (don't forget to mention its origin in the commit message) and then commit patch with your changes for this exercise.
If original code requires cleaning up (e.g. to conform code standards or to remove unneeded functionality) - do it as separate commit (prior to providing your changes).

Provide feedback