Engineering Standards Inventory

[vsmart]

Required Elements

If any elements in the below list are not checked, this repo will fail standards compliance.

• [x] Not running node 4 or below
• [x] Has at least some test coverage?
• [x] Has a README?
• [x] Has no hard-coded critical secrets like API keys?

Rubric

• [x] 1 pt Is in Version Control/Github ✅ (free points)
• 1-2 pt node version:
  • [x] 2 pt Best: running node 8+ 🏅
  • [ ] 1 pt Questionable: node 6
  • [ ] 0 pt Not ok: running node4 or below ⛔️
• [x] 1 pt No hard-coded config parameters?
• [x] 1 pt No special branches that need to be deployed?
• [ ] N/A 1 pt All production stacks on latest master?
• [x] 1 pt No hard-coded secrets like API keys?
• [x] 1 pt No secrets in CloudFormation templates that don’t use [secure]?
• [x] 1 pt CI enabled for repo?
• [x] 1 pt Not running Circle CI version 1? (Point awarded if using Travis)
• [ ] 1 pt nyc integrated to show test coverage summary?
• 1-3 pt test coverage percentage from nyc?
  • [ ] 3 pt High coverage: > 90%
  • [ ] 2 pt Moderate coverage: between 75 and 90% total coverage
  • [ ] 1 pt 0 - 74% test coverage
• 1-2 pt evidence of bug fixes/edge cases being tested?
  • [x] 2 pt Strong evidence/several instances noted
  • [ ] 1 pt Some evidence
• [ ] 1 pt no flags to enable different functionality in non-test environments?
• [x] 1 pt Has README?
• 1-2 pt README explains purpose of a project and how it works to some detail?
  • [ ] 2 pt High (but appropriate) amount of detail about the project
  • [x] 1 pt Some detail about the project documented, could be more extensive
• [x] 1 pt README contains dev install instructions?
• [ ] 1 pt README contains CI badges, as appropriate?
• 1-2 pt Code seems self-documenting: file/module names, function names, variables? No redundant comments to explain naming conventions?
  • [ ] 2 pt Strongly self-documented code, little to no improvements needed
  • [ ] 1 pt Some evidence of self-documenting code
• [x] 1 pt No extraneous permissions in IAM roles?
• [ ] 1 pt Stack has alarms for AWS resources used routed to PagerDuty? (CPU utilization, Lambda failures, etc.)
• [ ] 1 pt Stack has other appropriate alarms routed to PagerDuty? (Point awarded if no other alarms needed)
• [ ] 1 pt Alarms documented?
• [ ] master branch protected?
  • [ ] 1 pt PRs can only be merged if tests are passing?
  • [ ] 1 pt PRs must be approved before merging?
• [ ] 2 pt BONUS: was this repo covered in a deep dive at some point?

Total possible: 30 points (+2 bonus) Grading scale:

Point Total	Qualitative Description	Scaled Grade
28+ points	Strongly adheres to eng. standards	5
23-27 points	Adheres to eng. standards fairly well	4
18-22 points	Adheres to some eng. standards	3
13-17 points	Starting to adhere to some eng. standards	2
9-12 points	Following a limited number of eng. standard practices	1
< 9 points	Needs significant work, does not follow most standards	0

Repo grade: 14 -- Scaled Grade 2

Although the grade could be higher: a lot of the rubric related to alarms, monitoring does not necessarily apply to libraries like this.

cc @mapbox/assembly-line

[vsmart]

Recommendations

• add nyc for code coverage
• code style could be more self-documenting
• add CI badge to readme