[FFmpeg-devel] Maintainership Clarifications

[Luca Barbato]

We apologize that this clarification has been a long time coming. We
felt it necessary to allow the flaming to calm down and we had to
organize our thoughts and ideas, but nonetheless this should have been
posted much earlier.


* Intentions of the change

The intention was not to take away anything nor demotivate people.
However, the intention was to implement some changes in a final form
without having them watered down and filibustered in endless discussions.

We did not start out having all the answers prepared and ready or all
the processes defined. We have a vision and some general ideas, the
details are being developed as we go.


* Mission statement

- Work towards a healthy, encouraging and enjoyable environment for
  developing the FFmpeg code base. This shall be achieved through each
  individual's good behavior and intolerance of bad behavior, mutual
  respect, active and positive reviewing of submissions and other
  policies and processes targeted at conserving this environment.

- Aim to maintain and continually improve the code quality of FFmpeg.
  Peer review, regression testing and refactoring are some of the means
  to achieve this goal.

- Transform FFmpeg into a one-stop multimedia solution that fulfils all
  the needs of library users in one single package without the need for
  extra libraries for specific formats or needs. To this end we wish to
  implement native support, instead of external library wrappers, for
  all input formats.
  For output formats we recognize that in some cases external libraries
  will remain better for the foreseeable future and that in these cases
  wrappers are preferable, but where external libraries are low quality
  or unmaintained, we wish to supplant them.

We hope that the following clarifications along with future policies and
procedures will allow us to progress towards the goal of becoming the be
all and end all of multimedia software while allowing all involved to
enjoy the love of programming in a friendly atmosphere.


* Committers

We started with a small number of committers for practical reasons. One
bad example we had in mind was Janne's experience with the MythTV
project where inexperienced git users made a lot of beginner errors
after the switch.
The likely consequence is that the project will switch back to Subversion.

The list of committers was chosen for multiple reasons. One is available
time, the committers must do a lot of patch monkeying and should be able
to ensure that the patch queue does not slow down development. Another
is git experience, we wish to avoid mistakes and the fate of MythTV.

While the initial committers are trusted and mostly experienced with
git, mistakes are inevitable. The point is not that the committers be
infallible and incapable of making mistakes but rather that there should
be fewer mistakes and when mistakes occur, that they be fixed quickly
and effectively.

The list of committers is not fixed and we want more people to join in
the near future. Reinhard and Justin were already added. New patch
monkeys will be chosen by trust and competence through consensus in the
current committer team.

Committers are trusted not to break the review rules. Being a committer
is a duty, not a privilege.


* Administrators (AKA "roots")

Administrators are selected by trust and qualification and experience
originating from previous good admin work. Attila, M?ns and Diego, newly
joined by Janne, who managed our git transition and set up our patchwork
system, currently run the main project server. If more manpower is
required, Luca, who already hosts and runs roundup, and Reinhard are
available as backups.


* Review process

Reviews should be done on a best-effort basis by a person competent in
the area touched by the patch. The rule "no commits without review"
ensures that another set of qualified eyes looks over code previous to
commit. Adopting that policy for all developers - maintainers,
committers or first time contributors - puts everybody on equal footing.

If a patch touches a part of FFmpeg that nobody knows well, then review
is still done on a best-effort basis. In such a case it is not possible
to guarantee the same quality as when expert (in the field) reviewers
are available, but general code quality and portability can still be
maintained. A review shall then verify that the code does what the
author intended and that the change is sensible and beneficial.

We aim to make the lifetime of a patch or a branch minimal. To this end,
the amount of nitpicking on patches should be minimized. Documentation
typos or small coding style errors can be changed by committers without
a new round of review or a new patch submission by the original
contributor. Likewise, large patches should not live in separate
branches forever. Instead, committers and reviewers should actively
reach out to integrate branches into the main tree (i.e. we want to
avoid another ffmpeg-mt situation).

* Maintainers

A maintainer is a person experienced and/or knowledgeable in a specific
area, willing to make an effort to address bug reports about the area
and to shepherd outside contributions to the area into FFmpeg.

Maintainership is not file-based - many areas cover many files or even
all of FFmpeg. Maintainership is not code ownership. The project's code
is owned by all its members. No maintainer should veto changes to
specific files or make decisions without technical reasons just for
being the maintainer.

FOSS software development is based on copyright law and recognizing
individual contributions to the shared codebase. The revision control
tools in use nowadays even allow tracking attribution and thus
copyrights automatically. Nevertheless FOSS is about setting software
free, this includes giving up a certain amount of control. We must be
humble and encouraging towards those wishing to work on our code base
and willing to allow future developers to change our code and take it
in new directions.


* Personal Conflict Resolution

Conflicts, especially personal ones, have been the bane of the FFmpeg
project for many years. The current way of letting conflicts continue
and continue to escalate creates nothing but downward spirals and
unhappiness.

Personal conflicts shall be assisted by mediators in the future. When a
conflict between two (or more) people arises and threatens to spiral
downwards, anybody may ask for a mediator to step in. The role of the
mediator is to pull the fighters apart, calm them down, listen to each
side and try to restore and aid civil communication towards a resolution.

If reasonable communication fails, a mediator can ask for people to be
moderated on the mailing lists so that mails arrive with a delay and
combatants have a chance to calm down. Suitable mediator candidates
should be calm, level-headed, respected and more or less neutral in the
topic at hand. Being uncontroversial as a person and being a good
communicator is a plus. Currently, we believe Benjamin, Robert,
Reinhard, and Stefano are good candidates for this job.


* Code of Conduct

In order to foster a friendly and cooperative atmosphere where technical
collaboration can flourish we expect all members of the FFmpeg community
to be

- courteous, polite and respectful in their treatment of others,
- helpful and constructive in suggestions and criticism,
- stay on topic for the communication medium that is being used,
- be tolerant of differences in opinion and mistakes that inevitably get
  made by everyone.

Plus, we expect everybody to not

- flame and troll,
- insult,
- be offtopic or
- disruptive of our communication channels.

While we hope to keep disciplinary action to a minimum, repeated
violations of this policy will result in offenders getting temporarily
or permanently removed from our communication channels.