Add a CONTRIBUTING.md file

Github will display a link to it when a user wants to create an issue or
pull request.

Also make some minor adjustments to DOCS/contribute.md, which is
developer oriented, and for which I see no reason to merge it with
the new file.
This commit is contained in:
wm4 2015-12-22 23:09:18 +01:00
parent 8673343957
commit 3de6c9aa42
2 changed files with 33 additions and 9 deletions

22
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,22 @@
Reporting bugs
==============
- State your platform and mpv version.
- Attach a log file made with ``-v`` or ``--log-file=output.txt``.
- If you think this is file specific, upload a sample file and link it.
- Don't report multiple unrelated/barely related bugs in one issue.
- Read: https://mpv.io/bug-reports/
Asking questions
================
Preferably, asking questions should be done via IRC (#mpv on irc.freenode.net),
but asking questions by opening is also barely tolerated.
Sending patches
===============
See: https://github.com/mpv-player/mpv/blob/master/DOCS/contribute.md
In particular, be aware that all changes to GPL code must come with the
implicit agreement that they might be LGPLv2.1+ relicensed at a later point.

View File

@ -14,9 +14,11 @@ Sending patches
``git format-patch``. diffs posted as pastebins (especially if the http link
returns HTML) just cause extra work for everyone, because they lack commit
message and authorship information.
- When creating pull requests, be sure to test your changes. If you didn't, please
say so in the pull request message.
- 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).
- 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
situation with the patch applied, and past tense for the situation before
the change.
@ -27,8 +29,8 @@ Sending patches
For example, you fixed a crash in af_volume.c:
Bad: ``fixed the bug (wtf?)``
Good: ``af_volume: fix crash due to null pointer access``
- Bad: ``fixed the bug (wtf?)``
- Good: ``af_volume: fix crash due to null pointer access``
Having a prefix gives context, and is especially useful when trying to find
a specific change by looking at the history, or when running ``git blame``.
@ -53,10 +55,10 @@ Sending patches
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.
- 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).
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.
Code formatting
---------------