Design consensus should probably be achieved before a PR is made

[alexpyattaev]

Problem

Right now we do not have any specific format for approval of the overall design for a given change to the code. Some changes may not need it (they are small and/or fix an obvious issue in an obvious way). However, some changes may have uncertain implications and/or multiple possible solutions that could work. Making the code first and having to rework much of it due to design problems can be wasteful.

Proposed Solution

Instead of making code right away, one possible process could be:

1. Create issue just like this one
2. Assign people to review the issue same as you would for PR
3. Follow the discussion and iterate on the ideas for the design of a future PR. When appropriate, add "design approved" label.
4. Now the code can be made and a new PR linked to issue can be created
5. PR goes through review as usual
6. PR gets approved & merged
7. If the issue is fully resolved, it can be closed, else more PRs can be linked to it.

Feedback is welcome!

[bw-solana]

I agree. Picking the right people for step 2 is probably the trickiest part for new-ish people, but this can be learned over time or outsourced to old-timers.

I don't think we need to cudgel people into using this exact format (Github issue) for achieving design consensus, but the general steps/principles you outlined can hold regardless of the format. Getting tacit approval in Discord might suffice.

The nice thing with this is the incentive alignment is already there. If you want to bypass the process and jump straight to PR but get a design nack, you feel the pain.