[FFmpeg-devel] [libav-devel] Maintainership Clarifications

[Alex Converse]

On Sun, Mar 13, 2011 at 3:21 PM, 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.
>

Hear, hear!

Regards,

Alex Converse