[bisq-network/proposals] Add incubator space (#122)

[chimp1984]

> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

New large scale projects come with a lot of effort to review and audit the new code base. Maintainers are usually under heavy work load and large and risky PRs tend to get delayed a lot, which in turn makes it more cumbersome for the project developers to keep it in sync with master and results in frustration and stress for both sides. 

We should find a way how we can make such projects available without risking to add vulnerabilities to Bisq. One approach could be to use a kind of incubator stage where new projects get deployed under the Bisq umbrella but are marked as experimental and risky. 

I try to sketch here a possible guide line, but it is just a rough idea and totally open for discussion.

- A new candidate project needs to get sufficient support from active developers in a Bisq proposal. DAO voting is not required but can be helpful if needed. Acceptance in DAO voting does not guarantee inclusion but should be considered as additional information what BSQ stakeholders think of. All important decisions should be made in consensus, if there is clear lack of consensus no-action is preferred to any change (following the Bitcoin philosophy).
- If a project get sufficient support a Bisq maintainer creates a new Github repository. The benefit over creating a branch inside the Bisq repository is that Github isses are separated as well as pull requests. Having several incubator projects with lots of activity could spam/distract the main project quite a lot.
- The project is led by a project owner, who is usually the most active develper of that project.
- Projects should start as minimal viable products to avoid misaliged goals and expectations.
- The project owner is responsible for keeping his project in sync with master. Regular rebase should be done to keep change history clean.
- Testing is part of the responsibilty of the project owner. If there are multipe developers reviews should be done by those developers to reduce work load of Bisq maintainers. Merge is still done only by Bisq maintainers with the same quality criteria as in the main project.
- New dependencies need to be forked to a Bisq repository and not required code should be stripped out of to make code audit easier. This does not apply if the library comes from to big "trusted" company like Google. Keeping dependencies to an absolute minimun is important.
- Once the project is considered ready for usage, it need to show that there is interest from users. Some tools to get metrics for usage should be implemented. In the first step there will be no binary created, users need to run from source code. 
- After a certain level of usage is shown, maintainers can consider to provide a binary for the project. It still runs as a custom isolated binary.
- A clear message to the user need to make sure that they are aware of the incubator nature of the project (e.g. experimental, higher risk).
- The Bisq logo should add some "incubator - project x" label to make clear it is not the official Bisq app. 
- After a certain time when the project has proofen that it is stable, safe and has a sufficient user base maintainers can consider to include the feature into the Bisq main app, but there is no guarantee that this will ever happen. For some project it might be better to stay forever in incubator stage to reduce vulnerability surface for Bisq users who don't use that feature.

Current candidates for such a model would be the [API project](https://github.com/bisq-network/bisq/pull/3295) of @blabno and @mrosseel , the [Monero wallet project](https://github.com/bisq-network/proposals/issues/110) of @niyid and the [off-chain trade protocol project](https://github.com/bisq-network/proposals/issues/118).



-- 
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/122
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190919/2023f882/attachment.html>