Add updated version of old rules of engagement for core team

CODE_OF_CONDUCT.md

@@ -1,6 +1,4 @@
-# Code of Conduct
-
-By contributing toward this project you agree to the following code of conduct
+# Contributor Covenant Code of Conduct
 
 ## Our Pledge
 
@@ -16,21 +14,21 @@ appearance, race, religion, or sexual identity and orientation.
 Examples of behavior that contributes to creating a positive environment
 include:
 
-- Using welcoming and inclusive language
-- Being respectful of differing viewpoints and experiences
-- Gracefully accepting constructive criticism
-- Focusing on what is best for the community
-- Showing empathy towards other community members
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-- The use of sexualized language or imagery and unwelcome sexual attention or
+* The use of sexualized language or imagery and unwelcome sexual attention or
   advances
-- Trolling, insulting/derogatory comments, and personal or political attacks
-- Public or private harassment
-- Publishing others' private information, such as a physical or electronic
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
   address, without explicit permission
-- Other conduct which could reasonably be considered inappropriate in a
+* Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
 ## Our Responsibilities
@@ -57,7 +55,7 @@ a project may be further defined and clarified by project maintainers.
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at info@grassecon.org . All
+reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
 complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is
 obligated to maintain confidentiality with regard to the reporter of an incident.
@@ -77,8 +75,9 @@ available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.ht
 For answers to common questions about this code of conduct, see
 https://www.contributor-covenant.org/faq
 
+
+
+
 ...Try to keep in mind the immortal
 words of Bill and Ted, "Be excellent to each other."
 
-These documents are licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) https://creativecommons.org/licenses/by-sa/4.0/
-And further any software Grassrotos Economics supports is under licenced under GNU GENERAL PUBLIC LICENSE Version 3 https://www.gnu.org/licenses/

CONTRIBUTING.md

@@ -1,66 +1,16 @@
-# Contribution Guidelines
+Hello and welcome to the CIC Stack repository. Targeted for use with the ethereum virtual machine and a ussd capable telecom provider. 
 
-**Karibu sana!** Hello and welcome to the Grassroots Economics [project](https://gitlab.com/grassrootseconomics). This guide will help you understand the overall
-organization of the CIC project to get you started with contributing to the project. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged.
+__To request a change to the code please fork this repository and sumbit a merge request.__
 
-## Table of Contents
+__If there is a Grassroots Economics Kanban Issue please include that in our MR it will help us track contributions. Karibu sana!__
 
-- [Prerequisites](#Prerequisites)
-- [Scope of contributions](#Scope-of-contributions)
-- [Issues](#Issues)
-  - [Bugs](#Bugs)
-  - [Good first issues](#Good-first-issues)
-- [Git guidelines](#Git-guidelines)
-- [Merge request processs](#Merge-request-processs)
-- [Environment setup](#Environment-setup)
-- [Code style](#Code-style)
-- [Building-and-testing](#Building-and-testing)
+__Visit the Development Kanban board here: https://gitlab.com/grassrootseconomics/cic-internal-integration/-/boards/2419764__
 
-## Prerequisites
+__Ask a question in our dev chat:__
 
-Before contributing to the CIC Stack, ensure you have:
+[Mattermost](https://chat.grassrootseconomics.net/cic/channels/dev)
 
-- Read and accepted to abide by the Code of Conduct
-<!-- TODO: Add link to CoC -->
-- Read and accepted the Developers Certificate of Origin
-<!-- TODO: Add link to DCO -->
+[Discord](https://discord.gg/XWunwAsX)
 
-## Scope of contributions
+[Matrix, IRC soon?]
 
-We generally welcome all sorts or contributions. No contribution is too small. We gladly accept contributions such as:
-
-- Documentation improvements including inline documentation or even minor typos
-- Answering questions in issue discussions and pull requests
-- Fixing known bugs on our issue tracker
-- Reporting unknown bugs
-<!-- TODO: Add resposible disclosure guidelines -->
-- Securty issues through responsible disclosure
-
-## Issues
-
-Use the existing issue template and issue tags to correctly catagorize and issue when creating issues. Make sure to search for duplicated before creating a new issue.
-
-### Bugs
-
-If a bug is encountered and you can reproduce it:
-
-- Define its priority with an issue tag
-- Describe the steps to reproduce it while providing the version of the bugged service/library and your environment setup
-
-### Good first issues
-
-These are pre-tagged issues which are friendly (low barrier to entry and clearly defined tasks) for new contributors to get aquinted to the project.
-
-## Git guideleines
-
-<!-- TODO: Review after finalzing branching or forking model -->
-
-## Merge request process
-
-<!-- TODO: Review after core_contrib -->
-
-## Environment setup
-
-## Code style
-
-## Building and testing

CONTRIBUTING_CORE.md

@@ -0,0 +1,117 @@
+# CORE TEAM CONTRIBUTION GUIDE
+
+# 1. Transparency
+
+1.1 Use work logs for reflection of work done, aswell as telling your peers about changes that may affect their own tasks
+
+1.2 A work log SHOULD be submitted after a "unit of work" is complete.
+
+1.2.1 A "unit of work" should not span more than one full day's worth of work.
+
+1.2.2 A "unit of work" should be small enough that the log entries give useful insight.
+
+1.3 Individual logs are reviewed in weekly meetings
+
+<!--1.4 Bullet point list of topics and one or more sub-points describing each item in short sentences, eg;
+
+```
+- Core
+	* fixed foo
+	* fixed bar
+- Frontend
+	* connected bar to baz
+
+```-->
+
+1.4 Work log format is defined in []()
+
+1.5 Link to issue/MR in bullet point where appropriate
+
+1.6 
+
+
+# 2. Code hygiene
+
+2.1 Keep function names and variable names short
+
+2.2 Keep code files, functions and test fixtures short
+
+2.3 The less magic the better. Recombinable and replaceable is king
+
+2.4 Group imports by `standard`, `external`, `local`, `test` - in that order
+
+2.5 Only auto-import when necessary, and always with a minimum of side-effects
+
+2.6 Use custom errors. Let them bubble up
+
+2.7 No logs in tight loops
+
+2.8 Keep executable main routine minimal. Pass variables (do not use globals) in main business logic function
+
+2.9 Test coverage MUST be kept higher than 90% after changes
+
+2.10 Docstrings. Always. Always!
+
+
+# 3. Versioning
+
+3.1 Use [Semantic Versioning](https://semver.org/)
+
+3.2 When merging code, explicit dependencies SHOULD NOT use pre-release version
+
+
+# 4. Issues
+
+4.1 Issue title should use [Convention Commit structure](https://www.conventionalcommits.org/en/v1.0.0-beta.2/)
+
+4.2 Issues need proper problem statement
+
+4.2.1. What is the current state
+
+4.2.2. If current state is not behaving as expected, what was the expected state
+
+4.2.3. What is the desired new state.
+
+4.3  Issues need proper resolution statement
+
+4.3.1. Bullet point list of short sentences describing practical steps to reach desired state
+		
+4.3.2. Builet point list of external resources informing the issue and resolution
+
+4.4 Tasks needs to be appropriately labelled using GROUP labels.
+
+
+# 5. Code submission
+
+5.1 A branch and new MR is always created BEFORE THE WORK STARTS
+
+5.2 An MR should solve ONE SINGLE PART of a problem
+
+5.3 Every MR should have at least ONE ISSUE associated with it. Ideally issue can be closed when MR is merged
+
+5.4 MRs should not be open for more than one week (during normal operation periods)
+
+5.5 MR should ideally not be longer than 400 lines of changes of logic
+
+5.6 MRs that MOVE or DELETE code should not CHANGE that same code in a single MR. Scope MOVEs and DELETEs in separate commits (or even better, separate MRs) for transparency
+
+
+# 6. Code reviews
+
+6.1 At least one peer review before merge
+
+6.2 If MR is too long, evaluate whether this affects the quality of the review negatively. If it does, expect to be asked to split it up
+
+6.3 Evaluate changes against associated issues' problem statement and proposed resolution steps. If there is a mismatch, either MR needs to change or issue needs to be amended accordingly
+
+6.4 Make sure all technical debt introduced by MR is documented in issues. Add them according to criteria in section ISSUES if not
+
+6.5 If CI is not working, reviewer MUST make sure code builds and runs
+
+6.6 Behave!
+
+6.6.1 Don't be a jerk
+
+6.6.2 Don't block needlessly
+
+6.6.3 Say please

README.md

@@ -1,24 +1,19 @@
-## Community Inclusion Currency Stack (CIC Stack)
+# Community Inclusion Currency Stack (CIC Stack) 
 
-A custodial wallet and blockchain bidirectional interface engine for community inclusion currencies. Check the [CIC Stack summary](https://docs.grassecon.org/software) page for more information.
+A custodial evm wallet for executing transactions via USSD
 
-### Contributing
+## Getting started 
 
-See our [contribution guidelines](https://docs.grassecon.org/community/contrib/) for more details on:
+This repo uses docker-compose and docker buildkit. Set the following environment variables to get started:
 
-- Environment setup
-- Source Code Management (SCM) guidelines
-- Filing issues
+```
+export COMPOSE_DOCKER_CLI_BUILD=1
+export DOCKER_BUILDKIT=1
+```
 
-#### Code of Conduct
+To get started see [./apps/contract-migration/README.md](./apps/contract-migration/README.md)
 
-This project is released with a [Code of Conduct](https://docs.grassecon.org/community/conduct/). By participating in this project you agree to abide by its terms.
+## Documentation 
 
-### Community
+[https://docs.grassecon.org/cic_stack/](https://docs.grassecon.org/cic_stack/)
 
-- [Mattermost](https://chat.grassrootseconomics.net/cic/channels/dev)
-- [Discord](https://discord.gg/ud32KMgH76)
-
-### License
-
-Licensed under [GNU AGPLv3](https://gitlab.com/grassrootseconomics/cic-internal-integration/-/blob/master/LICENSE).