gaming/lutris
gaming/lutris
1
0
Fork 0
mirror of https://github.com/lutris/lutris synced 2024-11-02 13:31:16 +00:00
Code Issues Projects Releases Packages Wiki Activity

Update CONTRIBUTING document

Browse source
This commit is contained in:
Mathieu Comandon 2019-03-21 19:27:27 -07:00
parent 40e38a9235
commit 01e9c407fb
1 changed files with 47 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

71
CONTRIBUTING.md
View file

@ -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
-----------------------