Rethink Current Project/EPIC Usage

[evan-forbes]

We currently use different projects for core/app and node and EPICs never span across teams. With the coming merge and incorporation of CIPs into the protocol's development cycles, we should rethink this.

It has been suggested synchronously that we should consider dividing issues into different distinct sets or more vertical sub teams. For example we would have a global "protocol" project that tracks all issues typically associate with core/app/libs/node, followed by smaller projects that are either directly related to an ephemeral goal or perhaps longer lived project sub team.

EPICs should then describe high level goals or features that have reached social consensus either in form of a CIP or for non-consensus breaking changes simply by the implementers. The EPIC are therefore oblivious to the sub team structure. By default, all issues, including EPICs, opened in the "protocol" repos would be tracked in the "protocol" project as unplanned. The issue would change status when it has been scheduled to be completed by implementers.

[MSevey]

As a reference point, DevOps has a devops repo that is only used for issues and project tracking. Then that references larger EPICs and issues across all the devops related repos. Sounds like we want to do something similar here.

My reco would be to create a celestia repo. That repo could then be the home for the future merged repo as well and in the mean time could be that central place for the two teams to have high level EPICs