Hyperscale Race

What we are building: https://docs.google.com/document/d/1X558K8dC4OCcrbjK2ZMK0sjOSu6SLg6Awk9C9yaMXHI/edit

Figma designs to replicate: https://www.figma.com/file/CPfZkeob1dtxStjSuUUXDs/HyperscalePaid

Getting Started

First, clone the repo into a new folder (if you haven't yet):

git clone https://github.com/hyper-scale/race.git .

Next start dev enviroment:

docker-compose up -d

If you prefer to develop without the docker you can start mongodb only with:

docker-compose up -d mongo

MongoDB is pre-populated with test data.

You can now open http://localhost:3000 in your browser to see the result.

You can start editing the page by modifying pages/index.js. The page auto-updates as you edit the file.
API routes can be accessed on http://localhost:3000/api/hello. This endpoint can be edited in pages/api/hello.js.
The pages/api directory is mapped to /api/*. Files in this directory are treated as API routes instead of React pages.

Seed DB

If you are using MongoDB with docker-compose the test data is already there. Otherwise you can import test data manually:

mongoimport --host mongodb --port 27017 --db race --collection authors --mode upsert --type json --file seed/airtableAuthors.json --jsonArray
mongoimport --host mongodb --port 27017 --db race --collection applications --mode upsert --type json --file seed/airtableApplications.json --jsonArray

Linting

Don't forget to lint the code!

docker-compose exec web yarn lint

or for dev without docker:

yarn lint

Contributing

Pull Requests are welcome and encouraged! Make an issue first, and create a PR to assign it to yourself. Mark it for review when ready and we'll check to merge it.

Contribution process borrows from Collective Code Construction Contract (C4). Most important points:

Change on the project shall be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
The user or contributor should seek consensus on the accuracy of their observation, and the value of solving the problem.
To work on an issue, a contributor shall fork the project repository and then work on their forked repository.
To submit a patch, a contributor shall create a pull request (PR) back to the project.
A contributor shall not commit changes directly to the project.
To discuss a patch, people may comment on the pull request.
Maintainers should not merge their own patches except in exceptional cases, such as non-responsiveness from other maintainers for an extended period (more than 1-2 days).
Maintainers shall not make value judgments on correct patches.
Maintainers shall merge correct patches from other contributors rapidly.
Maintainers should ask for improvements to incorrect patches and should reject incorrect patches if the contributor does not respond constructively.
Any contributor who has value judgments on a correct patch should express these via their own patches.

TODO

License