Update dev guide

Author: gusty

DEVELOPER_GUIDE.md

@@ -4,10 +4,12 @@
 
  - Consistency: the design of this library should maximize consistency, this is relation between group of functions, argument types, types and abstractions they represent. By doing this, it's easier for the user to guess what are the expectations instead of relaying all the time to check docs and/or source code. Therefore naming should be carefully considered in order achieve this goal. 
  - Non intrusive: all additions to this library should not change existing functionality of F# language and FSharp.Core and in cases we they do change, we force the use to open a specific module/namespace 
- - Non opinionated: as much as possible we're not trying to force the user to solve problems in a specific way, instead we try to give generic ways to approach a problem from different angles. We think that specific ways of using this library should be eventually defined by a company what wants to use it to solve problems in a specific way and in order to achieve that goal, a small set of functions, type aliases can be added on top of F#+ for that purpose, but we try to keep the library as neutral as possible.
+ - Non opinionated: as much as possible we're not trying to force the user to solve problems in a specific way, instead we try to give generic ways to approach a problem from different angles. We think that specific ways of using this library should be eventually defined by a company that wants to use it to solve problems in a specific way and in order to achieve that goal, a small set of functions, type aliases can be added on top of F#+ for that purpose, but we try to keep the library as neutral as possible.
  - Trust users: we don't apply the principle of "removing functions that could be used in a wrong way", we assume the user has enough skills to decide what's a good use and what is a bad use of a specific function, we're not trying to educate users by hiding stuff, that's not the goal of this library, though there's a lot to learn, but for that there are general guidelines and normally there should be also specific ones for each company. This doesn't mean that we'll provide poor docs.
  - Coding style: we don't have a specific set of rules, but we try to stick to general coding conventions with some relaxation in order be able to align code in places where this is convenient. For instance when there's a big set of overloads, this makes it easier to read but also easier to edit the code with multiline editor support. The best advice is to try to copy existing style. For signatures, we try to follow FSharp.Core design, ie `'T` not `'a`.
- - PR's: try to keep them as atomic as possible, if a PR is found that touches many unrelated areas it will be asked to split in different PRs. A typical example is a PR that adds a specific functionality but also fix bugs, or typos in the docs. If we eventually revert that functionality, the other changes will be reverted as well which might not be desired. Draft PRs are encouraged and feel free to ask for advice in the middle of the code writing process.
+ - Naming commits: Use a very short and descriptive sentence in imperative mood, as if completing the sentence "If applied, this commit will ...". For more details [use this](https://cbea.ms/git-commit) as a reference.
+ - PR's: try to keep them as atomic as possible, if a PR is found that touches many unrelated areas it will be asked to split in different PRs. A typical example is a PR that adds a specific functionality but also fix bugs, or typos in the docs. If we eventually revert that functionality, the other changes will be reverted as well which might not be desired. Draft PRs are encouraged and feel free to ask for advice in the middle of the code writing process. Use the same naming convention as for commits.
+ 
  - This is F#: although F#+ contains some abstractions inspired in libraries used in other languages, those concepts are translated to F# standards and eventually adapted to fit better in F#.
 
 ### Extensions