Simulation Time Scale Run with Visualization

[Ly0n]

Create a simulation run that does x payout simulation to gather a statistic of distribution and visualize it with Jupiter Notebook.

The simulation run should be performed when doing unit testing.

[Ly0n]

I would like to increase the amount of payout so that we can test the payouts with amounts that are more interesting. For that it would be nice to simulate OpenSelery based on certain configurations. @kikass13 Could you support us with such a feature?

[Ly0n]

How should I configure OpenSelery so that about 1000€ are payed out over one month when the activity of the development keeps similar to the last 10 days?

[kikass13]

i could give it a try in the next week.

to clarify:

• let the user configure the passed time (for example: the last <30> days)
• automatically process, quantify and visualize the current development up until now
  • what does that mean, how to quantify?
• let the user configure the extrapolation by providing the capital (for example: <1000><€>)
• let the user configure the extrapolation by providing the payout period (for example: per <1> )
• output the necessary payout value btc_per_transaction: XXX to achieve the given parameters

There are some things that are inconsistent though ... there a multiple configuration parameters which have a role to play here. Shall the simulation just load the current config and use that as a basis or does the user have to input all parameters for the simulation to work properly?

example problematic values are for example:

• include_dependencies: True
• include_tooling_and_runtime: False
• min_contributions: 1
• included_dependency_contributor: 2
• number_payout_contributors_per_run: 5
• uniform_weight: 30
• consider_releases: True
• releases_included: 3
• release_weight: 70
• split_mode: "full_split"

[kikass13]

@Ly0n i did expect you to clarify the problematic config entries and how to deal with those :D

[Ly0n]

@kikass13: Needed to think about this a lot. I think the best way would be to change the HEAD of Git and step through the history creating a virtual transaction history file for every commit. This would mean you run OpenSelery with every commit again and again. This would create a real simulation letting the core code itself untouched. It would really be amazing for the end user to created a virtual transaction history like we already have. You could create the virtual transaction history by appending a virtual receipt with every run.

The other way would be to hard since the configuration will change in the future and we always have to change the simulation with every new weight etc.... @cornerman @krux02 What do you think?