Adjust collaboration guidelines to allow and even require PRs (Gitoxi…

…deLabs#163)

This is an outcome of the discussion in the PR and should help
to minimize surprises while increasing quality.

COLLABORATING.md

@@ -1,22 +1,31 @@
 
-### Guide
+### On how to work together
 
-- we do trunk-based development.
+- **we do trunk-based development** with a _twist_
    - Long lasting feature branches are discouraged, and instead small commits to `main` are preferred.
-- `main` must never be broken or show warnings. 
+   - **use preferably short-lived PRs when…**
+     - …you potentially want feedback on changes
+     - …changes would break _known_ downstream users, to allow those who are affected to influence the outcome towards greater value.
+   - **use issues for analysis and discussion of features and to track PRs**
+- **`main` must never be broken or show warnings**
    - An easy way to achieve this is to run `make tests check-size` before pushing or `make tests check-size && git push`.
    - If you're unsure about remembering to do this, we suggest using a pre-commit git hook.
-- if `main` breaks on CI _which can happen nonetheless_…
+- **if `main` breaks on CI** _which can happen nonetheless_…
     - …and you _do know_ the cause, please fix it immediately. If necessary by reverting the offending commit until a more durable fix is possible.
-    - …and you _do not know_ the cause, please open a PR to invite collaborators for their input. This is to avoid multiple collaborators trying to fix the issue independently,
-      causing merge-conflicts and confusion. We use this PR as synchronization primitive.
-- for crates **you own**
+    - …and you _do not know_ the cause, please open a PR to invite collaborators for their input. This is to avoid multiple collaborators 
+      trying to fix the issue independently, causing merge-conflicts and confusion. We use this PR as synchronization primitive.
+- **for crates _you own_**
     - feel free to make any kind of changes to it, including major ones.
     - please use `cargo smart-release` for publishing to crates.io as it will handle dependencies properly.
-- for crates **you do not own**
-    - for major or architectural changes please open a disccussion, an issue or a PR to allow
+- **for crates _you do not own_**
+    - for major or architectural changes please open a discussion, an issue or a PR to allow
       participation and don't merge until there is agreement.
     - for minor code changes, if they are minor, feel free to make any kind of change you need.
 
-The workflow can be changed after public discussion, just open a PR for it to get started.
+The workflow can be changed after public discussion - to get started, open a PR.
+
+
+Please see the [development guide] for more detailed information on how code and cargo manifests are structured.
+
+[development guide]: https://github.com/Byron/gitoxide/blob/main/DEVELOPMENT.md
 

DEVELOPMENT.md

@@ -21,7 +21,7 @@
    * we adhere to semantic versioning
    * while below 1.0, expect a greater amount of breaking changes, which are announced with minor versions
    * From 1.0, we will try hardest to keep the API and user interface non-breaking the closer to the user a library is. Thus the CLI should remain at version
-    1 for a long times. However, crates that make it up can change more rapidly and may see more major version changes over time.
+    1 for a long time. However, crates that make it up can change more rapidly and may see more major version changes over time.
 
 ## General