[FFmpeg-devel] Maintainership Clarifications

[Thilo Borgmann]

Am 14.03.11 11:40, schrieb 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.

+1