43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
|
# Contributing
|
||
|
|
|
||
|
|
Smithay's Client ToolKit (SCTK) is open to contributions from anyone.
|
||
|
|
|
||
|
|
## Coordination
|
||
|
|
|
||
|
|
Most discussion about features and their implementations takes place on github.
|
||
|
|
If you have questions, suggestions, ideas, you can open an issue to discuss it, or add your message
|
||
|
|
in an already existing issue if it fits its scope.
|
||
|
|
|
||
|
|
If you want a more realtime discussion there is a a Matrix room dedicated to the Smithay project:
|
||
|
|
[#smithay:matrix.org](https://matrix.to/#/#smithay:matrix.org). If you don't want to use matrix, this room is
|
||
|
|
also bridged to gitter: https://gitter.im/smithay/Lobby.
|
||
|
|
|
||
|
|
## Scope & Structure
|
||
|
|
|
||
|
|
SCTK aims to provide generic building blocks to write wayland clients, abstracting away the boilerplate of the
|
||
|
|
wayland protocol while allowing direct control when wanted. As such, it is composed of several loosely-coupled
|
||
|
|
modules, which can be used independenly of each other. This given, if you want to contribute a new feature to
|
||
|
|
SCTK, please consider these design points:
|
||
|
|
|
||
|
|
- The feature should be designed it is most general form, allowing it to be used by other projects, probaby
|
||
|
|
different from the exact use-case you have in mind.
|
||
|
|
- This new feature should not heavily depend on the other parts of SCTK if it can avoid it. As much as
|
||
|
|
possible, SCTK users should be able to use your feature alone.
|
||
|
|
|
||
|
|
## Pull requests & commits organisation
|
||
|
|
|
||
|
|
The development branch is the `master` branch, and it should be the target of your pull requests.
|
||
|
|
|
||
|
|
In general, single-purpose pull requests are prefered. If you have two independent contributions to make,
|
||
|
|
please open two different pull requests.
|
||
|
|
|
||
|
|
On the other hand, if you have changes that could technically be separated, but really belong together (for
|
||
|
|
example a new feature, that first require some refactoring before being introduced), it is okay to ship them
|
||
|
|
in the same pull request. However, to simplify the review work (and future reference to the commit history),
|
||
|
|
these changes should be separated in different commits. This will allow the reviewers to review each commit
|
||
|
|
independently, reducing the cognitive load.
|
||
|
|
|
||
|
|
At merge time, pull requests consisting of a single commit or of a few well-scoped commits will be rebased on
|
||
|
|
master. Pull requests which have accumulated several review-addressing commits will be squashed.
|
||
|
|
|