Standardizing the bounty solutions

[ainsleys]

We want to be able to bring all the bounty solutions together in our repo in some fashion, so that new users can use them as examples, fork them and build upon them, and so forth.

Option 1: create a new repo in EnigmaMPC for each bounty

Option 2: create a "bounties" repo which contains each bounty exactly as it is in a file structure

Option 3: create an "all samples" repo which enables users to get the enigma network up and running, and then deploy any of the contract they wish.

Challenges: Each bounty has it's own front-end, repo, server instructions... I am not sure how consistent they are.

This issue is opened so that we can provide feedback and do some research into which of these options is best (or if there's something better we didn't consider).

For reference, here are the bounty repos:

Benchmarking: https://github.com/nionis/enigma-benchmarking
NFT Lottery: https://github.com/nionis/enigma-non-fungable-token-lottery
Data validation: https://github.com/bshevchenko/enigma-data-validation
Access-Control: https://github.com/guix77/enigma-secret-access-control
Rock Paper Scissors: TBD

[levackt]

I like Option 3.

We can setup and maintain a standard server config, the client can use any JS framework and patterns en vogue.
If we have any internal examples like secret millionaires they can be homed there too.

[ainsleys]

I also like option 3... do you know what would be involved in getting from where we are now to that?

[levackt]

I also like option 3... do you know what would be involved in getting from where we are now to that?

At the moment, I'm only aware of the common build path for the enigma contracts. Will take a stab and see if there are some other hurdles.

[secretchaingirl]

It seems like git submodules might be an option?

https://git-scm.com/book/en/v2/Git-Tools-Submodules

But it's a more advanced usage of git. Basically, the layout would be the main repo, enigma-samples, with the sample repositories added as submodules:

enigmampc/enigma-samples

- enigma-secret-access-control
- enigma-benchmarking
- enigma-voting
etc.

To clone the entire samples repo:

git clone --recurse-submodules https://github.com/enigmampc/enigma-samples

I kind of like this approach, but I don't if it's in line with the standard server config and setup you were talking about above @levackt?

[ainsleys]

Interesting find, @lauraweindorf -- as long as we clearly document how people can get started on this. And, I think it's much easier if we can standardize the server config as @levackt and you discussed. That's something we should probably specify in future bounties, so we're not doing it later. In fact, if we set something like this up, we can ask for future bounties to be submitted as PRs to this repo...

[levackt]

Took a stab over the weekend and just pushed my naive approach to option 3

Initially I thought it's a little env config in each sample to compile and migrate to the server started at the root, and maybe this is still possible, discovery-cli expects a dir structure to exist relative to where it's run and this makes things tricky.

In the repo I made, only the client code is in the sample and it links to the root to reference the build.
I don't believe we gain enough from this to warrant the confusion it will cause.

Option 2 is suddenly looking a whole lot better :)

[nionis]

Hey guys, in my previous position I spent a significant amount of time optimising development workflow. Here is my opinion on how to improve the overall developer experience:

1. Create a project template

• The template should have a bare bones “hello world” implementation that encapsulates the whole project cycle.
• It should include both the secret contract source and dapp source code, the developer will be able to use GitHub's template feature to quickly get started with no additional setup. Here is an example, see "use template" button.
• discovery-cli can also use the template
• Template should use and encourage .env pattern.
• Readme should include instructions on how to setup enigma, setup the project, common pitfalls and performance tips.
  It should include a list of links to enigma approved examples and projects built by the community.
• Template source code should include “helper” functions like this and overall reduce boilerplate (perhaps we can move these functions to an npm package).
  In my experience I had to do a lot of copy pasting while developing, especially during tests.

2. Update examples to use the template, and keep them up to date with the latest template version.
   This will allow new developers to checkout the examples for help.

3. Traditional bounties / Contest bounties

• The bounty should require the developer to use the template.
• The repository should be in the developer's account while in development.
• Once the project is approved and paid out, it can be moved to the official enigma account.
• Then the template readme can be updated to include the new project.

---

Most of the time developers will not need to clone all of the examples, the proposed plan will keep the commit's separated for each project, and by using versioning developers will be able to see changes due to protocol updates and etc.

[levackt]

Great points Steve. Having the samples closely resemble the project generated by discovery-cli will make it easier to reason about. On the helpers, a test helper package like zeppelin's would be very handy indeed.

…

On Tue, 22 Oct 2019, 18:32 Steve, ***@***.***> wrote: Hey guys, in my previous position I've spent a significant time optimising development workflow. Here is my opinion on how to overall improve developer experience: 1. Create a project template - The template should be a bare bones “hello world” implementation that encapsulates the whole project cycle. - It should include both secret contract source and dapp source code, the developer will be able to use GitHub's template feature to get started quickly with no setup. Here is an example <https://github.com/sveltejs/template>, see "use template" function. - Template should use and encourage .env pattern. - Readme should include instructions on how to setup enigma, setup the project, common pitfalls. List links to enigma approved examples and projects built by the community. - Template source code should include “helper” functions like this <https://github.com/enigmampc/enigma-non-fungible-token-lottery/blob/0027497e87993a8b83b4dffc463c3d04352680ca/test/test_lottery.js#L32> and overall reduce boilerplate (perhaps we can move these functions to an npm package). In my experience I had to do a lot of copy pasting while developing, especially during tests. 1. Update examples to use template, and keep them up to date with template. This will allow new developers to checkout the examples for help. 2. Traditional bounties / Contest bounties - The bounty should have as a requirement for the develop to use the template. - The repository should be in the user’s account while in development. - Once the project is approved and paid out, it can be *moved* to the official enigma account. - Then the template readme can be updated to include the new project. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOPKQYNFJKB5BG5475N5F3QP4TLBANCNFSM4I5JXEJA> .

[secretchaingirl]

Great feedback @nionis!! It's great to have your knowledge and experience as input for this!

[ainsleys]

@nionis likewise, I really appreciate this. @lauraweindorf I wonder if your millionaire's problem example could be used as the template for something like this?

[secretchaingirl]

yeah @ainsleys, good idea. I can use it as a starting base to create a template, and include @nionis suggestions above. Would it make sense to track that work by adding an issue to our dev-help repo? And then everybody can review and make suggestions to finalize it. Including PRs to add helper functions :-D. I think @levackt and @nionis will have good input there.

[ainsleys]

That sounds great! let's do it.

…

On Wed, Oct 23, 2019 at 4:50 PM Laura Weindorf ***@***.***> wrote: yeah @ainsleys <https://github.com/ainsleys>, good idea. I can use it as a starting base to create a template, and include @nionis <https://github.com/nionis> suggestions above. Would it make sense to track that work by adding an issue to our dev-help repo? And then everybody can review and make suggestions to finalize it. Including PRs to add helper functions :-D. I think @levackt <https://github.com/levackt> and @nionis <https://github.com/nionis> will have good input there. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQWOLDNC56M7ZH2GDSYSDQQDPLNANCNFSM4I5JXEJA> .