[FFmpeg-devel] Maintainership Clarifications

[Ivan Kalvachev]

On 3/14/11, Luca Barbato <lu_zero at gentoo.org> wrote:
> 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.

Too little, too late.

I'm sorry, but most of these intentions have already been proven to be
false and there are quite many examples of actions taken that
contradict them. And I won't even start arguing why some of these
intentions are bad idea.

IMHO The FFmpeg revolution turned out to be a Bolshevik one. It came
with ideals of prosperity and equality, and ends with dictatorship of
a self-selected elite, oppression  and slowly growing stagnation.