How to audit our projects

We welcome any improvements from both internal and external developers. We also welcome external experts to audit our code, so our clients will be sure that we go in a right direction and our quality standards are high enough.

But, there are several topics that must be covered to conduct a successful code audit from a 3rd party person / company.

NDA

It all starts with signing NDA agreement. We recommend to use HelloSign service to send online NDAs.

After NDA is signed we can move further.

Agenda

What exactly we expect from code audit? We expect to improve our project quality. So, we need direct instructions what to do.

We expect other people to open bugs, if something does not look good. We mark accepted bugs as audit:pass and pay for them.

We also encourage our customers to pay for found bugs only.

Bug definition

Scope of the audit is the whole project. We welcome bugs about:

• code quality
• code readability
• security
• documentation quality and clearness
• build process
• CI process
• issues and code reviews quality
• deploy and release process

What is not a bug?

• Something with an explicit TODO label, that's how we mark tasks for the future selfs
• Something that has a documented explanation somewhere nearby (there are things to overcome!)
• Personal preference of the auditor: "I prefer tabs and this project uses spaces"
• Everything that violates initial requirements, eg.: "You should use MongoDB, it does not matter that requirements states to use MySQL"
• Something that cannot be proved: "This code is bad". How can you prove it? Compare it to: "This code is complex, because its cyclomatic complexity is 8"
• Somethings that is out of scope: "Consider adding this new shiny tool". Compare it to: "Consider adding X, it solved Y"
• Duplicates

Access

Then we invite auditors for three day access to our Gitlab project. We assign them developer status. So, everything is opened:

• code
• tasks
• CIs
• docs
• wiki

They can (and should!) audit everything.