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