Vendor things

third-party/vendor/smithay-client-toolkit/CONTRIBUTING.md

@@ -0,0 +1,42 @@
+# 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.
+