Byteball Use-a-Thon: A way to contract/reward Contributor efficiently - Architecture
Last week I write my intention that I probably going to build a way to contract/reward Contributor efficiently in developing a software-based project. In this post, I will talk about the possibles architecture that I can think of to build this kind of system. Ah yes, I'm not really familiar with the workflows of D-Apps development so any suggestion and/or critique is always welcome ( ͡ᵔ ͜ʖ ͡ᵔ )
Solution architecture level
Below is a list of the solution along with the architecture I can think of to contract/reward Contributor efficiently.
Phase -1 solution (easy)
Just open an issue, label it as good first issue + bounty and share it to many communities.
When someone makes PR related to that issue and it's being merged, ask their PayPal account and reward them.
Phase 0 architecture/solution (normal)
There is 2 best way I can think to realize it without losing the appetite to build it:
- starting and build from small things
- reinvent/rewrite something that already exists
Since I don't know the definition of small things for this problem, I will go with option 2 💩. So what I'm going to reinvent is the Byteball wallet which is based on copay. I think this is the best way for me to play around and get familiar with byteballcore and dsteem API. Basically, I'm going to build desktop wallet for Byteball with some Github and Steem related functionality/integration. I still not decided what form of integration for Github and Steem it would be, but some core functionalities that I think need to be added in this custom wallet are:
|deploy and write Smart contracts||in case the project maintainer want to set the payment condition just fo build trust|
|P2P payments in chat||in case the maintainer needs to give an extra tip|
|send Textcoins||in case the contributor doesn't have Byteball account beforehand|
For the technology stack, you probably can guess it by looking at this repo ▀̿̿Ĺ̯̿̿▀̿. Ah yes, for any electron-base-app haters out there (including mysefl 😆), I will add some productivity features that are related to managing project in Github just to justify the RAM that you are gonna sacrifice for electron. Just for info, GIMP only eat <50MB 😂
Phase 1 architecture (challenging)
This architecture are suitable if the project are runned by an organization.
Here you can see there is an additional bot that also act as an organization wallet. I'm thinking that organization bot and wallet should be self-hosted, mean that we only provide the runtime bot&wallet while managing and hosting that runtime is the organization responsibility. To make deploying runtime bot&wallet easy, we can add one-click deployment button (e.g Heroku or Azure button). The benefit for doing this is to leave the burden of maintaining and scaling that runtime into project maintainer which is the orgranization.
Phase 2 architecture (hard)
In case the desktop wallet become complex over time because the needs to add many functionality and integration, we probably need to refactor it and make plugin/add-on mechanism.
Each people probably have a different need for the feature set that available at that time so this probably can become a solution.
Phase X architecture/solution (< ━╤デ╦︻(▀̿̿Ĺ̯̿̿▀̿ ̿) }})
Well, this is a whole different subject. The idea is about to have distributed CI that incentify some people that share their machine to be used by the community. Some CI service I know that have this functionality is Gitlab CI. You can install Gitlab CI runner and share the machine you have to the rest of the world to run automation build/test that are from public repository. Those service are crucial for open source development, especially if it involved microncontroller, single-board computer, or GPU. However, it's not free for project hosted in Github plus it doesn't incentify the man who share his machines to run automation build/test from other repos. As a proof that this is important, you can do some quick survey on how many Arduino library out there that are well tested 😢.