The commit contains the following structural elements, to communicate
intent to the consumers of your library:

[TAG] module: describe your change in a short sentence (ideally < 50 chars)

Long version of the change description, including the rationale for the change,
or a summary of the feature being introduced.

Please spend a lot more time describing WHY the change is being done rather
than WHAT is being changed. This is usually easy to grasp by actually reading
the diff. WHAT should be explained only if there are technical choices
or decision involved. In that case explain WHY this decision was taken.

End the message with references, such as task or bug numbers, PR numbers, and
OPW tickets, following the suggested format:
task-123 (related to task)
Fixes #123  (close related issue on Github)
Closes #123  (close related PR on Github)
opw-123 (related to ticket)

TAGS
--------------------------------
[FIX] for bug fixes: mostly used in stable version but also valid
if you are fixing a recent bug in development version;

[IMP] for improvements: most of the changes done in development version 
are incremental improvements not related to another tag;

Others: commit tags other than [FIX] and [IMP] are allowed,
like [ADD], [REM], [REF] for refactors, [MOV], and others.

A scope may be provided to a commit’s type, to provide additional contextual
information, e.g., [ADD] new_module: add module for X.

BODY
--------------------------------
BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of
its optional body or footer section introduces a breaking API change
(correlating with MAJOR in semantic versioning).
A BREAKING CHANGE can be part of commits of any type.

SCHEMA
--------------------------------

[<TAG>] scope: <description>

[optional body]

[optional footer]
