Pull Request Guideline

Don't work on upstream master branch.
Treat your personal upstream branch (refer to Branches table) as a base for development.
Avoid direct committing to any branch in this repository except your 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 the 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.
- Separate branch (and PR) should be created for each task.
- These branches should be forked from your personal branch after merging the corresponding task from the master.
Try to give descriptive title to PR.
Treat the first message of PR discussion as PR description (you can edit it afterwards) and provide an explanation of the work.
Apply appropriate label to your PRs to reflect its readiness for review.
- When applying a new label - remove the previous, so each PR could have the only one label reflecting its status.
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.
PR merging:
- "Create a merge commit" should be used to clearly show the scope of each task and dependencies in history.

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.
Use checkpatch (instruction).

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 a 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