Development Guidelines

Processes and Procedures guidelines for development

Review Process

General Case: Every PR submitted needs to be seen by one other person before being merged.

In the case of backend changes: Because of the nuanced and specific nature of the knowledge contained in backend work, a change in backend can only be approved by another backend worker that has knowledge of the subject. If there is no knowledge of the subject, it’s the reviewers responsibility to ask the other team member to explain, or learn themselves, before reviewing.

In the case of the following changes, ALL team members need to be in agreement: Data models (‘Review’, ‘User’ JSON structures, etc.) API definitions (expected types, content length, etc.) Major UI updates Change in backend/frontend technology (React to Angular etc). Change in ML/DL algorithm being used (Naive Bayes -> Logistic Regression etc.) In these cases, a (short) case to justify the change has to be made.

In the case of the following changes, ALL team members need to be notified: New dependencies/libraries

Code Style

The recommended JS style guide to be used is the AirBnB one: https://github.com/airbnb/javascript Contains pretty much all of the most recent best practices for JS and minimizes shitty code. This can be loaded into ESLint via the eslint.config, and will auto-lint code to follow the guide.

Testing / CI / CD

CI will be done using CircleCI.

Frontend testing will be done via Jest and backend via Chai.

ML testing will be done via Pytest. (Tentative)