[RFC] cleanup & simplify processes

[sakulstra]

The api repo has been a quite fundamental part of the aave governance process over the last few years. That said over time it convoluted a bit and there are things that could be simplified imo to make the processes less error prone.

Website

The website has not been updated for months and is very much incomplete. As there's a well working governance ui at https://app.aave.com/governance/ and an ipfs preview mode at https://app.aave.com/governance/ipfs-preview/?ipfsHash=0xf6e50d5a3f824f5ab4ffa15fb79f4fa1871b8bf7af9e9b32c1aaaa9ea633006d I think at this point there's little point in trying to revive the website. Therefore I propose to remove the website to not confuse the few ppl accidentally accessing it https://github.com/aave/aip/pull/180

• [x] done

Accessing ipfs hashes 1

Ipfs hashes are currently stored in separate json files ipfs-aipfs/proposal-hash.json. While I guess that is okay, it would be nice to have a list with proposals and their respective hash. Therefore in #180 I added a ci which will automatically update a list inside the readme.

• [x] done

Typescript

While this repo is mostly *.md and json files the scripts are not necessarily easy to follow and update. Therefore i'd propose to use a simple ts-node flow so we can utilize some code type highlighting #180.

• [x] done

Dependency hygiene

There are a lot of outdated and unnecessary dependencies in npm, but also workflow. We should update to more recent versions of things #180

• [x] done

---

While for the above statements I don't expect much resistance, for the following I expect a bit more discussion needed.

Proposal naming

Currently there is a name generator in the codebase which forces ppl to use a HASH-TITLE nomenclatur which is hard on the eyes and makes finding aips more complicated than it must be: https://github.com/aave/aip/tree/master/content/aips While i'm fine with uppercase TITLE the HASH part seems like adding unnecessary complexity. For ipfs-hash generation the filename doesn't play any role, so i'd suggest to go with TITLE only. If there would ever be a naming-conflict ppl will realize (as the file already exists) and rename.

• [x] done (first part)

Removing state

Having status in the markdown seems like a unnecessary complexity to me. It's adding 0 value as a proposal will not be merged when it's not ready and once it is the state will always be the same. Would recommend to remove.

• [x] done

Branching

There's currently a mostly outdated master and a Pending-AIPs branch. I'd recommend to make Pending-AIPs the default branch and deleting master for now so that ppl start off with the correct branch. Once all the proposed changes are integrated we can then fork of to main and have main as the single working branch.

• [x] done

Accessing ipfs hashes 2

Currently ipfs hashes are only generated once the aip pr is merged. This makes kinda sense to prevent people from proposing unreviewed AIPs. That said, at the same time it doesn't as ppl might still rush ahead and create a proposal ditching the aip process all together. Therefore it might make sense to use a ci to comment current ipfs hash on pending prs automatically, so if they at least have correctly formatted ipfs hashes (even when not caring about a review). Also this allows ppl to preview the current hash in the ui so they can double check links render correctly etc. Disclaimer: not 100% sure if i agree with this myself :roll_eyes:

• [ ] pending

Lmk what you think and i'll create prs for the other topics as well.

[kartojal]

Hi @sakulstra ! First thanks for all your input and your PR cleanup #180. All points seems really logical and a must to maintain the state of this repository. I agree in all the points, and about "Accessing ipfs hashes 2" i think is a good addition to allow people to debug their IPFS proposals before they are merged.

[sakulstra]

In https://github.com/aave/aip/pull/201 I targeted:

• proposal naming
• removing state
• branching

For Accessing ipfs hashes i'm a bit overasked as you need a pinata key and have to handle fork prs properly. Currently don't have the capacity to look into this.