[bisq-network/proposals] Define Maintainer rules (#119)

[chimp1984]

I would suggest following rules for Bisq codebase maintainers which are partly derived from the way how it is handled in Bitcoin (to my knowledge, please correct if anything is wrong).

- Official Bisq maintainers (currently @ripcurlx , @sqrrm and @freimair) play a special role when it comes to reviewing and merging pull requests. They have basically a veto right by putting a **NACK** to a PR and then **no maintainer must merge that PR**. It will require a follow up utACK or ACK from the same reviewer before it can get merged.
- The review results of other developers should also be considered for the merge decision. They can be weighted by the devleopers contribution history (e.g. a contibutor who is already experienced and delivered valuable work in the past will have higher weight than a fresh dev). Any NACK should be taken seriously but of course we don't want to get in a deadlock by getting blocked by NACKs from non-maintainers.
- Any code change in the DAO package require a ACK/utACK from @ManfredKarrer. It is consensus code and carries high risk even with small changes which might look trival to other developers.
- Adding a dependency or version update need a proposal with clear argumentation why we need that change. We need to be very conservative with adding/changing dependencies and should try to reduce dependencies rather to add new ones. Only if the proposal gets clear support it can be merged. Removing a dependency is always welcome.
- For critical and more complex PRs the core maintainers should give enough time to receive reviews from other maintainers. Best to have at least 2 ACKs for any non trivial PR.
- If there is no consensus found the default policy is "no change".
- A new developer should to be active in Bisq for at least 3 months before he can be considered to become maintainer. The process is to make a bonded role request in the DAO, and after accepted by voting to set up the bond. After that the Github admin adds the dev as maintainer.
- Beside @ripcurlx none of the existing maintainers has set up the bond yet. This was ok, as we did not enforce encourage and bonding so far. We should define a timeline until when the existing maintainers need to make their bond as well. We could also require the voting process (no strong opinion on that, but would make the process more DAO conform).

Please add your opinon about the suggestions.
If you support that proposal please upvote, otherwise downvote.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/119
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190910/3b53ce3c/attachment.html>