+ Also if you have doubts about splitting or not splitting, do not hesitate to
+ ask/discuss it on the developer mailing list.
+@item
+ Do not change behavior of the programs (renaming options etc) or public
+ API or ABI without first discussing it on the ffmpeg-devel mailing list.
+ Do not remove functionality from the code. Just improve!
+
+ Note: Redundant code can be removed.
+@item
+ Do not commit changes to the build system (Makefiles, configure script)
+ which change behavior, defaults etc, without asking first. The same
+ applies to compiler warning fixes, trivial looking fixes and to code
+ maintained by other developers. We usually have a reason for doing things
+ the way we do. Send your changes as patches to the ffmpeg-devel mailing
+ list, and if the code maintainers say OK, you may commit. This does not
+ apply to files you wrote and/or maintain.
+@item
+ We refuse source indentation and other cosmetic changes if they are mixed
+ with functional changes, such commits will be rejected and removed. Every
+ developer has his own indentation style, you should not change it. Of course
+ if you (re)write something, you can use your own style, even though we would
+ prefer if the indentation throughout FFmpeg was consistent (Many projects
+ force a given indentation style - we do not.). If you really need to make
+ indentation changes (try to avoid this), separate them strictly from real
+ changes.
+
+ NOTE: If you had to put if()@{ .. @} over a large (> 5 lines) chunk of code,
+ then either do NOT change the indentation of the inner part within (do not
+ move it to the right)! or do so in a separate commit
+@item
+ Always fill out the commit log message. Describe in a few lines what you
+ changed and why. You can refer to mailing list postings if you fix a
+ particular bug. Comments such as "fixed!" or "Changed it." are unacceptable.
+ Recommended format:
+ area changed: Short 1 line description
+
+ details describing what and why and giving references.
+@item
+ Make sure the author of the commit is set correctly. (see git commit --author)
+ If you apply a patch, send an
+ answer to ffmpeg-devel (or wherever you got the patch from) saying that
+ you applied the patch.