Add incubator space

[chimp1984]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

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 of @blabno and @mrosseel , the Monero wallet project of @niyid and the off-chain trade protocol project.

[ripcurlx]

Sounds like a good idea to do so to get some beta testing and validation for big features that come with potential risks as well.

[blabno]

Will PRs to those incubated projects be compensated? That will require leaving behind the rule about compensating only the stuff that got shipped.

[ripcurlx]

Will PRs to those incubated projects be compensated? That will require leaving behind the rule about compensating only the stuff that got shipped.

Yes, I think that is the exception to the rule we have right now. If there is consensus on a bigger scale project that might have big potential in the future we could think about doing it that way. So the shippable code bits should be alpha/beta versions of the software in that separate repository.

[ripcurlx]

So in that case there still should be shippable software that can be used, but it won't be within the main production client.

[chimp1984]

@blabno

Will PRs to those incubated projects be compensated? That will require leaving behind the rule about compensating only the stuff that got shipped.

I would also suggest to start an incubator project with some minimal viable version so that a user can use it (in case of API, getBalance or getVersion could be such a starting version) and therefor its up for compensation if a PR is merged.

There might be also exceptions to even start funding work in earlier stages if there is stong consensus that this development is wanted (both in Github proposal support and DAO voting such should be expressed). For instance the off-chain protocol would not be usable before quite a bit of work is done. Without making such early work up for compensation it might be harder to find developers. But up for discussion if and where we make such exceptions....

[sqrrm]

I think this a good idea in general. The detail on how it should work will probably evolve over time. One of the main points is to have a more formalized way to build something more substantial, like the API, and not wait two years before it all can be merged or discarded.

I would say compensation schedule should be decided on per incubation project.

[ghost]

Concerning compensation.
Actually, Bisq has the DAO for that, but that doesn't necessarily exclude other funding ways. Especially if/when there are worries about issuing too much BSQs.
The Monero community has for example a Community Crowdfunding System (CCS) which works quite well -> https://ccs.getmonero.org/
We could think to something similar for Bisq ?

I find the incubator idea interesting (was also wondering hiw to deal with such cases ... without forking).
Am I right if I see incubator code as some form of add-ons to Bisq ?

[niyid]

OK. So how do we get this started? It appears #110 is a prime candidate?

Step 2: If a project get sufficient support a Bisq maintainer creates a new Github repository.

Are any maintainers available for this?

Step 3: The project is led by a project owner

I nominate @woodser to lead.

[chimp1984]

@freimair Can you add your feeback to the idea to get it accepted or rejected?

[erciccione]

I support this proposal and i would like to see it implemented.

[niyid]

I support this proposal and i would like to see it implemented.

@erciccione
This is great. I am still awaiting a Bisq maintainer to be nominated (either by self or others) for us to get this on the way. I expect this is simply to create a fork and with all other features such as Travis/Jenkins and any other CI tools?

[freimair]

please keep in mind that the underlying Bisq network will remain the same. If a incubator project destroys the p2p network, the original Bisq will no longer work either.

About compensation: if we do not compensate bigger projects early, we will not see bigger projects regularly. If a project is proposed and accepted, yes, compensate it.

Other than that, good to go.

[niyid]

@erciccione, @freimair

I guess all we have left to proceed with proposal #110 is a repository maintainer. Any ideas?

[chimp1984]

@niyid @woodser @ripcurlx @sqrrm @freimair
As this proposal was accepted by all maintainers and got upvotes from others as well we can consider it as accepted.
@ripcurlx Could you create a new repo for the monero wallet project?
@niyid Once the repo is set up (please have patience as devs are very busy with v1.2.0 release preparations) you can make a PR to that repo.

I think that is the best way to get that project forward.

[chimp1984]

@blabno @mrosseel And if ok for you I would suggest the same for the API project.

[blabno]

@ripcurlx may I request to get a new repo for API project?

[ripcurlx]

@ripcurlx may I request to get a new repo for API project?

sure - I'll set it up right now

[ripcurlx]

How shall we call this kind of repos?

• incubator-bisq-api
• incubator-bisq-monero-wallet

[niyid]

• incubator-bisq-monero-wallet

@ripcurlx @erciccione @woodser

It is more of Monero integration than merely only about the wallet. I will go with incubator-bisq-xmr-integration. Any other suggestions?

Thanks and regards.

[ripcurlx]

@blabno I've just created https://github.com/bisq-network/incubator-bisq-api
@woodser, @niyid, @erciccione I've just created https://github.com/bisq-network/incubator-bisq-xmr-integration

I've added the existing Bisq maintainers as maintainers and added @blabno as a maintainer for the API and @woodser for the xmr integration

[niyid]

@ripcurlx

Thanks a lot.

@woodser

I will create the PR to the incubator-bisq-xmr-integration repository within a few hours.

Regards.

[m52go]

I think we need to establish some conventions for compensation on incubator projects. I understand the incubator's potential utility for major long-term projects, but it opens a huge gap in governance.

An incubator project can theoretically do a huge amount of work in perpetuity for code separate from the original project and acquire a significant degree of influence over the original code base that they don't contribute to. I don't think that's right.

At a minimum, there should be milestones (approved by consensus, with time and cost estimates) so stakeholders have some metric of how well the original proposal is being executed and some basis for knowing whether money the network is allocating to these experiments is worthwhile or not.

Maybe there could also be a percentage discount on compensation (perhaps something like 50-75%) until the project is either delivered (merged to the main repository) or until it hits the predefined milestones approved by consensus. Only at these points can the developers obtain the remaining 50-75% of their compensation.

This is effectively a crude "vesting" schedule like what you would get working for a startup with an unknown/uncertain future exit.

Without some such defined mechanism, the DAO is a blank check for funding code that lacks all the governance of the original code base.

[niyid]

there should be milestones (approved by consensus, with time and cost estimates)
...
Without some such defined mechanism, the DAO is a blank check for funding code that lacks all the governance of the original code base

@m52go

Thanks for raising these issues.

I am in complete agreement with having guidelines that will prepare the investors with an idea of expectations in cost and timeline.

In the example of incubator-bisq-xmr-integration, the following are the expected deliverables/timelines (without the associated cost) and which initially existed as separate proposals/issues:

• proposal Add Monero wallet features to Bisq #51
• issue Propose how to integrate Monero wallet into Bisq bisq#1863
• proposal Integrate transaction proof verification for Monero #86
• proposal Automate altcoin trading #87

All these Monero related proposals and issues were grouped under a single umbrella and the Monero Wallet Integration (also earlier captured as a separate proposal) and Monero Transaction Proof Verification were the first to be targeted for implementation and can each be considered milestones; and they have been delivered in incubation with others to follow.

Without an existing guideline on compensation, I was compelled to force this discussion towards the establishment of the compensation framework.

With that in mind, I think it will then be proactive to retroactively update Proposal 110 - which as the title might wrongly suggest is merely to implement Monero Wallet Integration- with cost estimates that can actually be agreed to even before the DAO process.

Regards.

[chimp1984]

I think after the 1.2 release and the voting cycle we need to re-discuss the idea about incubator projects. The current situation that the project devs are the maintainers is dangerous. Being under the Bisq umbrella requires that a Bisq developer who has already earned enough reputation by past work is playing that role. Or maybe the incubator idea is not feasible with Bisq's current resources at all and we need to look out for other alternatives (keeping it in the project devs repo but find a model for compensation)?

[niyid]

I think after the 1.2 release and the voting cycle we need to re-discuss the idea about incubator projects. The current situation that the project devs are the maintainers is dangerous. Being under the Bisq umbrella requires that a Bisq developer who has already earned enough reputation by past work is playing that role. Or maybe the incubator idea is not feasible with Bisq's current resources at all and we need to look out for other alternatives (keeping it in the project devs repo but find a model for compensation)?

Yes indeed. There has to be a discussion and the guidelines have to be cemented. I had expected @wiz, @ripcurlx and others to be the repository custodians but I can understand they are currently very busy.

But I think @m52go has already provided the scaffolding to build on in this post except you have reasons to have doubts on his suggested process implementation.

As you suggested, all issues should be ironed out after 1.2 release and the voting cycle.

In my opinion, the incubator project structure is a sound idea that only needs a bit of tweaking; I already see v2 Protocol and Bisq on Rust (Risq) being initiated as incubator projects.

Regards.

[blabno]

The current situation that the project devs are the maintainers is dangerous.

Current situation is that incubator devs are being slowed down by maintainers.

Maybe there could also be a percentage discount on compensation (perhaps something like 50-75%) until the project is either delivered

I thought that Bisq lacks developers and wants to incentivise them with good money.
I'm not sure if anybody who looked at API example would be willing to undertake similar risk.
It has proven that developers who undertake large tasks, may not be compensated at all and the acceptance criteria can change on weekly basis.
I think that such uncertainty will effectively keep most of good devs away.

[clearwater-trust]

First,
We need to fund QUALITY DISPUTE RESOLUTION. Bisq is a trading platform not a coding incubator.

[niyid]

@woodser

Hello. I think v1.2 may have reached a level of stability. Would you consider rebasing the incubator-bisq-xmr-integration repository now?

Regards.

[woodser]

@niyid I have rebased incubator-bisq-xmr-integration. Where there were conflicts, I resolved with the latest in the bisq repository.

[niyid]

@niyid I have rebased incubator-bisq-xmr-integration. Where there were conflicts, I resolved with the latest in the bisq repository.

Great news. Thanks a lot.

[mpolavieja]

@chimp1984 should we close this proposal?

[chimp1984]

Yes, please mark it as declined.

[niyid]

OK. So this has been rejected?

[chimp1984]

Yes, i turned out to be a bad idea as we dont have the resources to maintain it.

[erciccione]

@chimp1984 What about projects which are currently developed in incubators waiting to be integrated?