mirror of
https://github.com/lutris/lutris
synced 2024-09-05 15:33:40 +00:00
Update CONTRIBUTING document
This commit is contained in:
parent
40e38a9235
commit
01e9c407fb
|
@ -1,34 +1,48 @@
|
|||
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
|
||||
[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.
|
||||
|
||||
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
|
||||
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)
|
||||
where you can submit bash scripts for various open source games and engines we
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
-----------------------
|
||||
|
@ -41,33 +55,35 @@ the repository and executing Lutris from there.
|
|||
./bin/lutris -d
|
||||
|
||||
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.
|
||||
If you are working on a branch implementing new features, such as the `next`
|
||||
branch, it might introduce new dependencies. Check in the package configuration
|
||||
files for new dependencies, for example Debian based distros will have their
|
||||
dependencies listed in `debian/control` and in `lutris.spec` for RPM based
|
||||
ones.
|
||||
If you are working on newly written code that might introduce
|
||||
new dependencies, check in the package configuration files for new packages to
|
||||
install. Debian based distros will have their dependencies listed
|
||||
in `debian/control` and RPM based ones in `lutris.spec`.
|
||||
|
||||
Under NO circumstances should you use a virtualenv or install dependencies with
|
||||
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
|
||||
sure to always use PyGOject from your distribution's package manager.
|
||||
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. Also
|
||||
install the necessary GObject bindings as described in the INSTALL file.
|
||||
|
||||
Formatting your code
|
||||
--------------------
|
||||
|
||||
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
|
||||
pylint checks. We highly recommend that you install a pylint plugin for your
|
||||
code editor. Once you have pylint set up to check the code, you can configure
|
||||
it to use 120 characters max per line instead of 80.
|
||||
developers from going back and fixing your code, please make sure your code
|
||||
passes pylint checks. We highly recommend that you install a pylint plugin in
|
||||
your code editor. Once you have pylint set up to check the code, you can
|
||||
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
|
||||
the CodeFactor page: https://www.codefactor.io/repository/github/lutris/lutris
|
||||
|
||||
When writing docstrings, you should follow the Google style
|
||||
(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.
|
||||
|
||||
|
@ -88,6 +104,13 @@ In order to run the test, you'll need to install nosetests and 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
|
||||
-----------------------
|
||||
|
||||
|
|
Loading…
Reference in a new issue