Code review for security advisory coverage applications

Note: The following is provided as a suggested 'checklist' for code reviews, with some modifications to the existing process thrown in.

The largest change is a divergence from the "Stick to a review from start to finish" concept, as the proposal below would encourage folks to jump on/off at the start/end of any given gate. The motivation behind this is to allow for less experienced reviewers to get involved in the review process without committing to a full review (as the 'full review' commitment can be a bit daunting for a new contributor).

A second suggestion is the use of tags to validate the clearing of each gate, as discussed in other sections of this group. While there is consensus within the group that tagging gates could become unwieldly; auto-creating tags is not something that can be done today 'out-of-the-box' ... so I've attempted to group the checklist into sections, thus minimize the tags used while still providing the abililty to use tagging to indicate where an application sits in the process.

The third is the addition of an 'Applicant Review' gate. I personally feel that the linkage between 'Module Review' and granting of the 'Full project access' roles should be severed, allowing the flexibility within the process to grant one without a dependancy on the other (think '3 module reviews = full access', or 'Module denied, but access granted' situations) ... which would then allow a 'probationary' period for new applicants, where we can ensure they are up to speed on managing the issue queue, project packaging, and git best practices before setting them free in contrib.

In any case, my proposed 'checklist' is posted below - feedback, comments, suggestions for improvement are encouraged!

We should have regular code review process reviews to go through the issues that have risen and to make changes as needed to the process.

See zzolo's post for some context.

This page is dedicated to documenting issues of the code review process. These issues should be backed with data when possible and should always be objective. Please do not propose solutions here (you can do propose solutions here).

If you just want to complain about something, please file a complaint.

See zzolo's post for more context.

We need defined leadership for the Code Reviewing. See zzolo's post for some context.

This page is dedicated for reviewees (users that have had a review) to tell their story. If you have been through a review, comment on this page to tell your story.