Lets add these two points to vote that came out of the discussion and see the reaction.
This vote is to see what subjects we do agree already and what needs update / clarification :-) Where are all +1 we can implement already, where is at least one -1 that needs fix, where is 0 we may clarify some information with the feedback provided :-) 18. Pull Requests should be as small as possible and focused on only one functional change. Different functional changes should be provided in separate Pull Requests. Remember that breaking changes are not welcome. Pull Requests must not break overall build, runtime, and compatibility, especially for other components. When changes must be bundled together in order to maintain functionality and self-compatibility, exception can be made, and this must be clearly stated there is no other way. 19. "Lazy consensus" is a situation where PR is auto-merged into the upstream when not enough reviews are done in predefined time (i.e. there are no minimum required positive reviews within two weeks time). PR should initially be treated according the general rules (4 independent reviewers); After a week without enough reviewers, a call should be made on the mailing list, explaining why the PR can't be split into smaller PRs; After two weeks without any reviewers, we could merge if the above conditions are met and we have at least one independent reviewer. This may solve situation when we don't have enough people to review it (or we are not interested in that). It prevents people from forking the project just to be able to develop their stuff: *we* *really would not like that*. The PR's author is still responsible for fixing some bugs if found in the future. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
