mirror of https://github.com/mpv-player/mpv
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:
parent
8673343957
commit
3de6c9aa42
|
@ -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.
|
|
@ -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
|
||||
---------------
|
||||
|
|
Loading…
Reference in New Issue