You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current code review guide has a bit of path dependency, where we call it code review because we started with human peer review. However, this doesn't really align with industry terminology around this sort of tooling, and it's unclear why we have it.
Firstly, we should move this section into the security module to make it clear that it's part of our security assurance suite (there's performance too).
Secondly, we should align our terminology and re-emphasise the "code review" phrasing in favour of terms like static analysis and static application security testing (SAST).
Thirdly, we should reframe the entire value pitch and core of the documentation to focus on the security suite as a whole. That is, we should talk about static analysis (linting rules), dependency security (dependabot), and software development lifecycle (SDLC) tools (deployments); these can then link across to our other docs for each of these parts.
Fourth...ly? (Not sure that's a word.) We should reframe the static analysis page to talk more about the existence of the phpcs rules than altis-review specifically, and offer two options for using it (1: rules via phpcs, maybe mention running in GitHub Actions; 2: altis-review bot)
The text was updated successfully, but these errors were encountered:
Our current code review guide has a bit of path dependency, where we call it code review because we started with human peer review. However, this doesn't really align with industry terminology around this sort of tooling, and it's unclear why we have it.
Firstly, we should move this section into the security module to make it clear that it's part of our security assurance suite (there's performance too).
Secondly, we should align our terminology and re-emphasise the "code review" phrasing in favour of terms like static analysis and static application security testing (SAST).
Thirdly, we should reframe the entire value pitch and core of the documentation to focus on the security suite as a whole. That is, we should talk about static analysis (linting rules), dependency security (dependabot), and software development lifecycle (SDLC) tools (deployments); these can then link across to our other docs for each of these parts.
Fourth...ly? (Not sure that's a word.) We should reframe the static analysis page to talk more about the existence of the phpcs rules than altis-review specifically, and offer two options for using it (1: rules via phpcs, maybe mention running in GitHub Actions; 2: altis-review bot)
The text was updated successfully, but these errors were encountered: