• Authors should be the ones who gonna merge their owns PR's
• Issues should contains motivations (bugs, improvements) + a plan/suggestion of how to address it, spending time on design/brainstorming strategies to tackle a problem is needed to achieve a solid result
• Every issue or design issue we should put the spot on the problem and enable the teammates to bring suggestions/opinions/questions to a design call, but is responsibility of the owner of the task to present the main arch and sell it to the team. This ties on the point of spending time on design understanding the task/problem
• Promoting design calls where a problem can be presented as well discussed with the ones interested. The call should serve as a point of brainstorming for problems, and the OUTCOME SHOULD BE a plan for addressing the discussed problem, so suggestions about splitting the problem, drawing and even bring other code to the discussion are all valid points.
• PR's pointing to development should be reviewed, however PR's that is not pointing development should be rethought. For example, PR 1 has couple changes and is merging branch ABC into DEF and DEF in the future will be merged into development, so the review process kinda be duplicated (gonna review the same changes twice). So, instead think about raising a PR merging DEF into development and then raising a PR merging ABC into development, that reaches the same results using a straight line of reviews.