<div dir="ltr">Hi stackers, <div><br></div><div><b>Issue</b></div><div><b>-------</b></div><div><br></div><div>Projects are becoming bigger and bigger overtime. </div><div>More and more people would like to contribute code and usually core reviewers</div><div>team can't scale enough. It's very hard to find people that understand full project and have enough time to do code reviews. As a result team is very small under heavy load and many maintainers just get burned out. </div><div><br></div><div>We have to solve this issue to move forward. </div><div><br></div><div><br></div><div><b>Idea</b></div><div><b>------</b></div><div><br></div><div>Let's introduce subsystems cores.</div><div><br></div><div>Really it's hard to find cores that understand whole project, but it's quite simple to find people that can maintain subsystems of project. </div><div><br></div><div><br></div><div><b>How To</b></div><div><b>-----------</b></div><div><b><br></b></div><div>Gerrit is not so simple as it looks and it has really neat features ;)</div><div><br></div><div>For example we can write own rules about who can put +2 and merge patch based on changes files. </div><div><br></div><div>We can make special "subdirectory core" ACL group. </div><div>People from such ACL group will be able to merge changes that touch only files from some specific subdirs.  </div><div><br></div><div>As a result with proper organization of directories in project we can scale up review process without losing quality. </div><div><br></div><div><br></div><div><b>Thoughts?</b></div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div>