Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module: Payments #2

Open
Paulito123 opened this issue Dec 18, 2022 · 0 comments
Open

Module: Payments #2

Paulito123 opened this issue Dec 18, 2022 · 0 comments

Comments

@Paulito123
Copy link

Paulito123 commented Dec 18, 2022

Karma-bot

The Karma-bot is intended to support various processes in the 0L organization. It sources from and stores data in json files on Github, making it pluggable for other applications and ensuring that no strict dependency is created between the app and the data it produces. The different functionalities of the Karma-bot are defined as modules.

Payment Module

The Payment Module aims at taking away friction from the internal payment processes. It adds proactivity to the current process by notifying payers about their payments due and prevents fidling with json files. Consistent and validated data is generated along the way that can be used as input for reporting applications and dashboards. This module facilitates linking transactional data with mission/task data. For now, this linkeage is done manually by the payer.

Features

  1. Ingest standardized data from work organizing applications like Github and Jira.
  2. Payment proposals are to be generated and sent to the agreed payer only.
  3. From Github:
  • new completed issues can be used as mission input for the payment proposals
  • issues from different repositories can be ingested (core dev, analytics, marketing, ...)
  • ideally, a customized template is created for issues that have some pre-determined fields like Payer, Payee(s) and Bounty.
  1. Payments data should be stored in payments.json and stored on github.
  2. contributors.json is used as a source for looking up address information.
  3. The payer updates payment proposals with tx hash keys to keep track of the link between mission data and transactions made in its context.
  4. This module can make use of an internal relational database, if needed to ensure high availablity, but needs to stay in sync with the json db on Github.

Process flow

Payment_process_github_20221030

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant