Improve the current ADR system

[RiccardoM]

Today I was taking a look at the ADRs that we have merged and the ones that are currently opened as PRs and I think we have the following problems:

• All the modules we have inside the staging folder do not have an ADR (x/posts, x/subspaces, x/reports)

• There are some ADRs that are related to such modules and are PRs (eg. docs(adr): ADR-001: Reports type field replacement #616, docs(adr): ADR-002: Reports save/edit operation #640, docs(adr): ADR-003: End-blocker check on unregistered users #624, docs(adr): ADR-007: Reports delete operation #639)

• Based on the definition of AD:

  An Architectural Decision (AD) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant

  Some of the merged ADR should have not been ADR in the first place since they are very small changes with no architecture impact (ADR-005, ADR-009)

For this reason I propose the following things:

1. Create a new branch called backlog where we keep the current staging folder
2. Remove the staging folder from the master branch
3. Re-organize all the ADRs by:
   1. Closing the currently opened PRs listed above
   2. Deleting the non-ADRs listed above
   3. Re-numbering the merged ADRs
4. Create one ADR per currently staging module just like Cosmos does before starting to work on that module (subspaces, posts, reports in this order). Each ADR for single module should be created AFTER the dependent module ADR has been merged:

   subspaces ADR -> merge -> posts ADR -> merge -> reports ADR
   

5. Once the ADR for a module is merged, use the backlog branch to get the module implementation, change it to adapt it to the ADR and then merge it inside the "master" branch

What do you guys think?

[kwunyeung]

I'm fine with the suggested workflow.

[dadamu]

I agree with this workflow.

[leobragaz]

I'm okay with this, would you like me to take care of these changes? @RiccardoM

[RiccardoM]

I can take care of this