Merge pull request monero-project#215

8097275 Docs: add 'Proposals' caveat to contributing guide. (anonimal)
4ca5991 Docs: add commit-title caveat to contributing guide. (anonimal)

doc/CONTRIBUTING.md

@@ -8,11 +8,25 @@ To contribute a patch, please execute the following:
 3. Create a topic branch
 4. [**Sign**](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) your commit(s)
 5. PR to branch ```development```
-   - In general, commits should be [atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) and diffs should be easy to read. For this reason, please try to not mix formatting fixes with non-formatting commits.
    - Commit messages should be verbose by default, consisting of a short subject line (50 chars max), a blank line, and detailed explanatory text as separate paragraph(s) - unless the title alone is self-explanatory.
+   - Commit title should prepend class or aspect of project. For example, "HTTPProxy: implement User-Agent scrubber. Fixes #193." or "Garlic: fix uninitialized padding in ElGamalBlock".
    - If a particular commit references another issue, please add a reference. For example "See #123", or "Fixes #123". This will help us resolve tickets when we merge into ```master```.
+   - In general, commits should be [atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) and diffs should be easy to read. For this reason, please try to not mix formatting fixes with non-formatting commits.
    - The body of the pull request should contain an accurate description of what the patch does and provide justification/reasoning for the patch (when appropriate). You should include references to any discussions such as other tickets or chats on IRC.
 
+## Proposals
+To contribute a proposal, please review our [open issues](https://github.com/monero-project/kovri/issues) for existing proposals. If what you propose is not there, then [open a new issue](https://github.com/monero-project/kovri/issues/new).
+
+Even though our C4 dictates that we merge everything, we ask that you open a proposal for the following reasons:
+
+1. A proposal open up communication
+2. A proposal show that the contributor respects the input of all project collaborators
+3. A proposal allows seamless collaborator input in an open forum
+3. A proposal saves time if a collaborator is working on a similar feature/issue
+4. A proposal prevents catasrophes and mishaps or allows collaborators to prepare for catasrophes and mishaps
+
+*Not* opening a proposal will *not* prevent you from contributing; we will merge what you PR - but a proposal is highly recommended.
+
 ## TODO's
 - Do a quick search in the codebase for ```TODO(unassigned):``` and/or pick a ticket and start patching!
 - If you create a TODO, assign it to yourself or write in ```TODO(unassigned):```