GETTING_STARTED.md

Getting started

1. Install Node.js (LTS version).
2. Install Git.
   • If you are not comfortable with the Git command line tool, you may use GitHub Desktop (https://desktop.github.com/). Take a look at https://acmcsuf.com/1st/ if this is your first time contributing to an open source project.
3. Create a fork of acmcsuf.com, similar to https://github.com/diamondburned/acmcsuf.com.
4. (Optional; required on some pages) Create an access token.
5. Follow these instructions to add it to your dev environment.

Local development setup

1. Create a local clone of your FORKED repository.
2. Open a terminal inside your local clone and run npm i to install the required dependencies (We use svelte for much of the codebase along with Typescript and some utility libraries).
3. Run npm start (or npm run dev) to boot up the local development server and navigate to localhost:5173 in your web browser and you should have a local copy of the website.

Pushing a code change

1. Create a new branch, DO NOT work directly off the main branch.
2. Open src/routes/+page.svelte, this is the root of the website, in other words, the front page when you visit the website.
3. Go ahead and change the title of the website to anything you want and head over to src/routes/hero.svelte and change the text of the header.
4. Whenever applicable (it’s not in this case), write unit tests for any new functions or components you create.
5. Once you’re satisfied your changes, you MUST use npm run all to run all tests, lints, and formatting necessary for a release build, otherwise the automated build test will fail.
6. Commit and push your changes.

Submitting a pull request for review

1. Once you’re ready to submit your changes for review, head back over to the main repository and click on Pull Requests → New pull request.
2. Your pull request should contain.
   1. A clear and descriptive title (Please do not use "Fixed #123").
   2. A clear description that describes, in detail, what you changed and how.
   3. A link to the issue that you resolved (if applicable).
   4. Any screenshots if your change affects something visible on the website or that you believe would help the reviewer understand your changes.
   5. Examples of good PRs:
      1. https://acmcsuf.com/pull/477
      2. https://acmcsuf.com/pull/469
      3. https://acmcsuf.com/pull/401
   6. Examples of bad PRs:
      1. https://acmcsuf.com/pull/359
      2. https://acmcsuf.com/pull/357
3. Use the "Reviewers" panel on the top-right side of the PR page to request a review. Reach out to your chosen reviewer outside of GitHub to ensure they are aware of your code review request.
4. As a requester, it is courteous to give your chosen reviewer a heads-up before formally requesting a review. As a reviewer, it is also common courtesy to respond to code review requests within 24 hours.
5. If your chosen reviewer does not review your code within 24 hours, consider gently reminding them. Alternatively, if necessary, you can request a review from another individual.
6. Once your changes have been approved, you have permission to merge your changes, and your changes should be merged with a SQUASH and NOT a merge commit.

Further reading

If you aren’t already familiar with Svelte, you should go through the official Svelte tutorial, as much of the codebase uses it.

Once you’re ready to start, you may either assign yourself to an issue or ask for an issue to be assigned to you. I’d recommend starting with issues tagged “Good First Issue”.

For a more in depth overview of the codebase, check out CONTRIBUTING.md and ARCHITECTURE.md.