/race

Primary LanguageJavaScript

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

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.

Linting

Don't forget to lint the code!

docker-compose exec web 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

TBD