Hello All, I am sharing my work related to my action item to recommend changes to improve the contribution and review process. Please feel free to comment, question, and challenge anything. The statement and proposal are right up front followed by supporting information. Problem Statement - Code is not being submitted in a timely manner. Associated observations made my community members - "There are too many reviewers" with an example of citing 18 reviewers. "Reviews aren't conducted in a timely manner" from data shared in community meetings. "Unclear if we have the Gerrit Review process documented for StarlingX" captured in Community Meeting Minutes. Proposal - - Document how many (+1) reviews, not reviewers, are required. - Create and adopt "rules-of-the-road" that is behavioral and etiquette based. - Create and maintain an overall submission and review performance dashboard to manage "stuck" reviews. Initial "rules-of-the-road" proposal - Rules-of-the-Road for change owners -Test code prior to asking for review. -Provide access to test environment to reviewers. -Ask for reviews on Matrix. Assure reviewers are only in the attention set when you are waiting for a response from them. -Respond to reviewers and "your turn" within 24 hours. Rules-of-the-Road for reviewers -Respond to review requests and "your turn" within 24 hours. -Remove yourself as a reviewer if you don't intend to respond and notify the change owner. -Test the code as part of your review. -Document and share your review details to benefit both change owners and core reviewers. My Conclusions - - StarlingX does have basic Gerrit Review process flow documented. - StarlingX does not have submission and review documented well enough to objectively evaluate the problem statement or associated observations. -Gerrit documentation and documented Best Practices do not recommend limiting the number of reviewers. -StarlingX does not have a documented reviewer or change owner response time expectation. However, both exceed documented best practices. - StarlingX should not limit the number of reviewers; it should articulate how many (+1) reviews are required in the approval flow. - Documented, practiced, enforced(?) "rules-of-the-road" for change owners and reviewers would improve current submission/review performance. Reference Documents and Summary Information - Opendev Developer's Guide https://docs.opendev.org/opendev/infra-manual/latest/developers.html#code-re... OpenStack Using Gerrit https://docs.openstack.org/contributors/code-and-documentation/using-gerrit.... StarlingX Contributor Guide https://docs.starlingx.io/contributor/ StarlingX Submission Guidelines https://docs.starlingx.io/developer_resources/code-submission-guide.html Gerrit Code Review - Attention Set https://gerrit-review.googlesource.com/Documentation/user-attention-set.html Coreboot Gerrit Etiquette and Guidelines https://doc.coreboot.org/contributing/gerrit_guidelines.html How To Review Changes the OpenStack Way https://docs.openstack.org/project-team-guide/review-the-openstack-way.html I have notes from each document that I can share if desired. -steve