MIPs Templates for everyone!

[anajuliabit]

└── moonwell-contracts-v2/
    └── src/
        └── proposals/
            ├── templates/
            │   ├── RewardsDistributionTemplate.sol
            │   ├── MarketRecommendations.sol
            │   └── SystemDeployment.sol 
            └── mips/
                ├── x01/
                │   ├── x01.json
                │   ├── x01.md
                │   └── x01.sh
                ├── m01/
                │   ├── m01.json
                │   ├── m01.md
                │   └── m01.sh
                ├── b01/
                │   ├── b01.json
                │   ├── b01.md
                │   └── b01.sh
                └── o01/
                    ├── o01.json
                    ├── o01.md 
                    └── o01.sh

In the shell file, we set various environment variables such as TEMPLATE_PATH, PRIMARY_FORK_ID, MTOKENS_PATH, and EMISSIONS_PATH. CI will check if the PR contains new MIPS. If so, it will execute the shell file to configure the environment variables. After that, it will run the proposal and display the calldata in the PR comments. We should also consider potential edge cases. What should we do about highly specific proposals that are unlikely to occur again, making the template unnecessary?

[ElliotFriedman]

What should we do about highly specific proposals that are unlikely to occur again, making the template unnecessary?

For proposals that are one-offs, we will write the solidity proposal as we currently do. The infrastructure around this system can detect if the proposals are written in solidity or they are can be run as configs from JSON files.

[ElliotFriedman]

└── moonwell-contracts-v2/
    └── src/
        └── proposals/
            ├── rewards/
            │   └── RewardsDistributionTemplate.sol
            │   └── b01/
            │       ├── b01.md
            │       ├── b01.sh
            │       └── b01.json
            │
            ├── market-recs/
            │   └── MarketRecommendations.sol
            │   └── o01/
            │       ├── o01.md
            │       ├── o01.sh
            │       └── o01.json
            │
            └── system-deployment/
                └── SystemDeployment.sol
                └── x01/
                    ├── x01.md
                    ├── x01.sh
                    └── x01.json

When I think about the folder structure, this is what comes to mind.

The main question I ask is how do we know which type of proposal is which? The easier it is to tell what the type of a proposal is, the easier is it to run integration tests, build shell scripts to automate actions, and do our onchain calldata checks.

For each proposal type, we should have a separate integration test suite to check onchain calldata. We can then git rid of many of the existing solidity proposal files, and as long as we have onchain calldata integration tests and have rewritten the Solidity proposal files into json with this new structure, we should be able to test this new calldata generation infrastructure.

[anajuliabit]

@ElliotFriedman how about getting the latest proposal on run-latest-proposal CI for printing calldata? If we store all the proposal folders in the same directory as I suggested, it will be easy to. The way I though about this question: how do we know which type of proposal is which? is using the TEMPLATE_PATH env inside the .sh file