[FFmpeg-devel] Maintainership Clarifications

[Dominik 'Rathann' Mierzejewski]

On Sunday, 13 March 2011 at 23:21, Luca Barbato wrote:
> We apologize that this clarification has been a long time coming.

Way too long. You should've thought about that before you started
your revolution.

> We felt it necessary to allow the flaming to calm down

Doing it without any real explanation (you still haven't provided one)
surely helped the flames calm down (not).

> 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.

Hell is paved with good intentions. The harsh reality is that you
caused both. You will have to live with the consequences.

> 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.

Great planning.

> * 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.

Ah, so negative reviews are not allowed anymore? Good way to improve
patch acceptance ratio, I suppose.

[...]
> * 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

Trusted by whom?

[...]
> 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.

Ah, so you created your inner circle of power and won't let anyone who
you don't like in.

[...]
> * Administrators (AKA "roots")
> 
> Administrators are selected by trust and qualification and experience
> originating from previous good admin work.

Again, trust from whom? And who judged the quality of that 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.

Well, I guess with this group of people, even without clearly defined
rules of conduct you won't get any conflicts of interest, but personally
I don't trust you guys anymore.

> * 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).

If these are the review rules then the code quality will surely go down.

> * 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.

What if coming up with a justification to reject a patch takes time
and the maintainer is busy? Will the patch get approved by someone
else and applied over maintainers objections?

[...]
> * 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.

I think you're blowing things out of proportion here. I can remember
maybe two serious conflicts: one with Uoti and one with Mans.

[...]
> * 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.

What about maintainership and commit access? Who decides the removals
and how?

Regards,
Dominik

-- 
MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan