Thanks for starting this. I think you would make a great review admin. Few suggestions, though. It would help to use the Review Template, to make sure all of the additional points are covered (eg, licensing) and to include an automated review, which includes a git hash (so people know exactly what you reviewed). The review template also encourages you mark which items in the code walkthrough are suggestions, strong suggestions that should be fixed before stable release, and what are truly the application blockers. Identifying the true blockers will help streamline the process. To quote @klausi from my mentoring page,
Project application reviews are basically sanity checks, so while providing all details what can be improved is very valuable we have to consider what issues are really blocking approval. If we are confident that the people basically know what they are doing then we should not hold them back. With the exception of security issues and licensing issues.
I personally set applications to needs work if the API usage is so painfully wrong or the spaghetti code issues just keep piling up. Fortunately people fix all the things from pareview.sh, so at least we don't have to complain about coding standards anymore.
Comments
Thanks for starting this. I
Thanks for starting this. I think you would make a great review admin. Few suggestions, though. It would help to use the Review Template, to make sure all of the additional points are covered (eg, licensing) and to include an automated review, which includes a git hash (so people know exactly what you reviewed). The review template also encourages you mark which items in the code walkthrough are suggestions, strong suggestions that should be fixed before stable release, and what are truly the application blockers. Identifying the true blockers will help streamline the process. To quote @klausi from my mentoring page,