DOCS/contribute.md: some updates

Some of this is outdated by years. I don't think we even have
MPlayer-style randomly formatted source files anymore (except
stream_dvd.c).

DOCS/contribute.md

@@ -17,6 +17,14 @@ Sending patches
 - All new code must be LGPLv2.1+ licensed, or come with the implicit agreement
   that it will be relicensed to LGPLv2.1+ later (see ``Copyright`` in the
   repository root directory).
+- You must be either the exclusive author of the patch, or acknowledge all
+  authors involved in the commit message. If you take 3rd party code, authorship
+  and copyright must be properly acknowledged. If the license of the code is not
+  LGPLv2.1+, this must be mentioned.
+- Don't use fake names (something that looks like an actual names, and may be
+  someone else's name, but is not your legal name). Using a pseudonyms is
+  allowed if it can be used to identify or contact you, even if whatever
+  account you used to submit the patch dies.
 - When creating pull requests, be sure to test your changes. If you didn't,
   please say so in the pull request message.
 - Write informative commit messages. Use present tense to describe the
@@ -55,11 +63,14 @@ Sending patches
   additional cosmetic changes in the same file you're working on. But don't do
   something like reformatting a whole file, and hiding an actual functional
   change in the same commit.
-- If you add a new command line option, document it in options.rst. If you
-  add a new input property, document it in input.rst. Changes to the user
-  interface (options, properties, commands) should be documented in
-  interface-changes.rst. Changes to libmpv should be documented in
-  client-api-changes.rst.
+- Changes to command line options (addition/modification/removal) must be
+  documented in options.rst. Changes to input properties or input commands must
+  be documented in input.rst. All changes to the user interface (options,
+  properties, commands) must be documented with a small note in
+  interface-changes.rst (although documenting additions is optional, and
+  obscure corner cases and potentially be skipped too). Changes to the libmpv
+  API must be reflected in the libmpv's headers doxygen, and should be
+  documented in client-api-changes.rst.
 
 Code formatting
 ---------------
@@ -130,11 +141,6 @@ mpv uses C99 with K&R formatting, with some exceptions.
     }
     ```
 - Remove any trailing whitespace.
-- If the file you're editing uses formatting different from from what is
-  described here, it's probably an old file from times when nobody followed a
-  consistent style. You're free to use the existing style, or the new style, or
-  to send a patch to reformat the file to the new style before making functional
-  changes.
 
 General coding
 --------------
@@ -150,7 +156,6 @@ General coding
 - Prefer fusing declaration and initialization, rather than putting declarations
   on the top of a block. Obvious data flow is more important than avoiding
   mixing declarations and statements, which is just a C90 artifact.
-- tech-overview.txt might help to get an overview how mpv is structured.
 - If you add features that require intrusive changes, discuss them on the dev
   channel first. There might be a better way to add a feature and it can avoid
   wasted work.