Add a documentation for governance and roles and responsibilities

In order to follow FLOSS good practice, we should consider adding a documentation for governance and roles and responsibilities.

The [OpenSSF website](https://github.com/coreinfrastructure/best-practices-badge/blob/main/docs/other.md#governance) more precisely argue the following:

* The project MUST clearly define and document
its project governance model (the way it makes decisions,
including key roles).

*Details*: There needs to be some well-established documented way
to make decisions and resolve disputes.
In small projects, this may be as simple as "the project owner and lead
makes all final decisions".
There are various governance models, including benevolent dictator
and formal meritocracy; for more details, see
Governance models.
Both centralized (e.g., single-maintainer) and decentralized
(e.g., group maintainers) approaches have been successfully used
in projects.
The governance information does not need to document the possibility
of creating a project fork, since that is always possible
for FLOSS projects.

*Rationale*:
There are many different governance models used by a wide array of
successful projects. Therefore, we do not believe that we should
specify a particular governance model. However, we do think it is
important to have a governance model, and clearly define it, so that
all participants and potential participants will know how decisions
will be made.
This was inspired by the
OW2 Open-source Maturity Model,
in particular RDMP-1 and STK-1.

* The project MUST clearly define and publicly document the key roles in the
project and their responsibilities, including any tasks those roles
must perform. It MUST be clear who has which role(s), though this
might not be documented in the same way.

*Details*: The documentation for
governance and roles and responsibilities
may be in one place.

Rationale: Much knowledge about the project roles builds up
over the years, and is not sufficiently passed down to new people.
Documenting the roles can help recruit, train, and mentor new
project members. Projects may choose document the roles
and responsibilities in one place, and identify who has the roles
separately, so that the project doesn't need to update the role
information when people change roles.
The goal is to make underlying assumptions clear.

No file, documentation location, or project entry point is named. Start by reviewing the repository’s existing documentation and governance practices, then identify where governance, roles, responsibilities, and current role holders should be recorded. Done means the project’s decision process and key responsibilities are publicly documented.

Written by the indexing model from the issue text.