mirror of
https://github.com/lutris/lutris
synced 2024-09-15 22:09:55 +00:00
Update CONTRIBUTING document
This commit is contained in:
parent
40e38a9235
commit
01e9c407fb
|
@ -1,34 +1,48 @@
|
||||||
Contributing to Lutris
|
Contributing to Lutris
|
||||||
======================
|
======================
|
||||||
|
|
||||||
Finding issues to work on
|
Finding features to work on
|
||||||
-------------------------
|
---------------------------
|
||||||
|
|
||||||
If you are looking for issues to work on, have a look at the
|
If you are looking for issues to work on, have a look at the
|
||||||
[milestones](https://github.com/lutris/lutris/milestones) and see which one is
|
[milestones](https://github.com/lutris/lutris/milestones) and see which one is
|
||||||
the closest to release then look at the tickets targeted at this release.
|
the closest to release then look at the tickets targeted at this release.
|
||||||
|
|
||||||
If you are less experienced with code, you can also have a look at the issues
|
|
||||||
that are [not part of a release](https://github.com/lutris/lutris/milestone/29)
|
|
||||||
which usually include problems with specific games or runners.
|
|
||||||
|
|
||||||
Don't forget that lutris is not only a desktop client, there are also a lot of
|
Don't forget that lutris is not only a desktop client, there are also a lot of
|
||||||
issues to work on [on the website](https://github.com/lutris/website/issues)
|
issues to work on [on the website](https://github.com/lutris/website/issues)
|
||||||
and also in the [build scripts repository](https://github.com/lutris/buildbot)
|
and also in the [build scripts repository](https://github.com/lutris/buildbot)
|
||||||
where you can submit bash scripts for various open source games and engines we
|
where you can submit bash scripts for various open source games and engines we
|
||||||
do not already have.
|
do not already have.
|
||||||
|
|
||||||
Other areas can benefit non technical help. The Lutris UI is far from being
|
|
||||||
perfect and could use the input of people experienced with UX and design.
|
|
||||||
Also, while not fully ready, we do appreciate receiving translations for other
|
|
||||||
languages. Support for i18n will come in a future update.
|
|
||||||
|
|
||||||
Another area where users can help is [confirming some
|
Another area where users can help is [confirming some
|
||||||
issues](https://github.com/lutris/lutris/issues?q=is%3Aissue+is%3Aopen+label%3A%22need+help%22)
|
issues](https://github.com/lutris/lutris/issues?q=is%3Aissue+is%3Aopen+label%3A%22need+help%22)
|
||||||
that can't be reproduced on the developers setup. Other issues, tagged [need
|
that can't be reproduced on the developers setup. Other issues, tagged [need
|
||||||
help](https://github.com/lutris/lutris/issues?q=is%3Aissue+is%3Aopen+label%3A%22need+help%22)
|
help](https://github.com/lutris/lutris/issues?q=is%3Aissue+is%3Aopen+label%3A%22need+help%22)
|
||||||
might be a bit more technical to resolve but you can always have a look and see
|
might be a bit more technical to resolve but you can always have a look and see
|
||||||
if they fit your area of expertise.
|
if they fit your area of expertise. Also, while not fully ready, we do
|
||||||
|
appreciate receiving translations for other languages, support for i18n will
|
||||||
|
come in a future update.
|
||||||
|
|
||||||
|
Note that Lutris is not a playground or a toy project. One cannot submit new
|
||||||
|
features that aren't on the roadmap and submit a pull request for them without
|
||||||
|
agreeing on a design first with the development team. You can submit such pull
|
||||||
|
requests but they will have to be updated with necessary changes from code
|
||||||
|
reviews of the development team. This is not only about writing good code but
|
||||||
|
also about providing good design for the overall product. Make sure to post all
|
||||||
|
the revelant information in a ticket or on the pull request. New features must
|
||||||
|
at all times have a valid use case based on an actual game, be very specific
|
||||||
|
about why you are implementing a feature otherwise it will get rejected.
|
||||||
|
Avoid adding options in the GUI or introducing new installer directives for
|
||||||
|
things that can be automated. Lutris focuses heavily on automation and on doing
|
||||||
|
the right thing by default. Only introduce new option when absolutely
|
||||||
|
necessary.
|
||||||
|
|
||||||
|
Contributors are welcome to suggest architectural changes or better code design
|
||||||
|
if they feel like the current implementation should be improved but please take
|
||||||
|
note that we're trying to stay as lean as possible. Requests introducing complex
|
||||||
|
architectural changes for the sake of "modularity", "Unix pureness" or subjective
|
||||||
|
aspects might not be received warmly. There are no plans for any rewrite in
|
||||||
|
another language or switching to another toolkit.
|
||||||
|
|
||||||
Running Lutris from Git
|
Running Lutris from Git
|
||||||
-----------------------
|
-----------------------
|
||||||
|
@ -41,33 +55,35 @@ the repository and executing Lutris from there.
|
||||||
./bin/lutris -d
|
./bin/lutris -d
|
||||||
|
|
||||||
Make sure you have all necessary dependencies installed. It is recommended that
|
Make sure you have all necessary dependencies installed. It is recommended that
|
||||||
you keep a stable copy of the client installed with your package manager to
|
you keep a copy of the stable version installed with your package manager to
|
||||||
ensure that all dependencies are available.
|
ensure that all dependencies are available.
|
||||||
If you are working on a branch implementing new features, such as the `next`
|
If you are working on newly written code that might introduce
|
||||||
branch, it might introduce new dependencies. Check in the package configuration
|
new dependencies, check in the package configuration files for new packages to
|
||||||
files for new dependencies, for example Debian based distros will have their
|
install. Debian based distros will have their dependencies listed
|
||||||
dependencies listed in `debian/control` and in `lutris.spec` for RPM based
|
in `debian/control` and RPM based ones in `lutris.spec`.
|
||||||
ones.
|
|
||||||
|
|
||||||
Under NO circumstances should you use a virtualenv or install dependencies with
|
Under NO circumstances should you use a virtualenv or install dependencies with
|
||||||
pip. The PyGOject introspection libraries are not regular python packages and
|
pip. The PyGOject introspection libraries are not regular python packages and
|
||||||
it is not possible to pip install them or use them from a virtualenv. Make
|
it is not possible for pip to install them or use them from a virtualenv. Make
|
||||||
sure to always use PyGOject from your distribution's package manager.
|
sure to always use PyGOject from your distribution's package manager. Also
|
||||||
|
install the necessary GObject bindings as described in the INSTALL file.
|
||||||
|
|
||||||
Formatting your code
|
Formatting your code
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
To ensure getting your contributions getting merged faster and to avoid other
|
To ensure getting your contributions getting merged faster and to avoid other
|
||||||
developers from going back and fixing your code, please make your code pass the
|
developers from going back and fixing your code, please make sure your code
|
||||||
pylint checks. We highly recommend that you install a pylint plugin for your
|
passes pylint checks. We highly recommend that you install a pylint plugin in
|
||||||
code editor. Once you have pylint set up to check the code, you can configure
|
your code editor. Once you have pylint set up to check the code, you can
|
||||||
it to use 120 characters max per line instead of 80.
|
configure it to use 120 characters max per line instead of 80.
|
||||||
|
|
||||||
You can help fixing formatting issues or other code smells by having a look at
|
You can help fixing formatting issues or other code smells by having a look at
|
||||||
the CodeFactor page: https://www.codefactor.io/repository/github/lutris/lutris
|
the CodeFactor page: https://www.codefactor.io/repository/github/lutris/lutris
|
||||||
|
|
||||||
When writing docstrings, you should follow the Google style
|
When writing docstrings, you should follow the Google style
|
||||||
(See: https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html)
|
(See: https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html)
|
||||||
|
You should always provide docstrings, otherwise your code wouldn't pass a
|
||||||
|
Pylint check.
|
||||||
|
|
||||||
Do *not* add type annotations, those are not supported in Python 3.4.
|
Do *not* add type annotations, those are not supported in Python 3.4.
|
||||||
|
|
||||||
|
@ -88,6 +104,13 @@ In order to run the test, you'll need to install nosetests and flake8:
|
||||||
|
|
||||||
pip3 install nose flake8
|
pip3 install nose flake8
|
||||||
|
|
||||||
|
QAing your changes
|
||||||
|
------------------
|
||||||
|
|
||||||
|
It is very important that any of your changes be tested manually, especially if
|
||||||
|
you didn't add unit tests for the patch. Even trivial changes should be tested
|
||||||
|
as they could potentially introduce breaking changes from a simple oversight.
|
||||||
|
|
||||||
Submitting your changes
|
Submitting your changes
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue