Contributing

TL;DR

1. Name your branch appropriately
   1. fix_issue-number_short-description-of-issue for bug fixes. Omit issue-number if there is no issue/ticket on GitHub for the bug
   2. feat_issue-number_feature-name for features. There should be an issue number for features.
2. Run npm run pre-commit before committing your code.
3. Push your changes up and open a PR to main
4. Once your changes have been approved they will be squashed into main

If you're new to development start here

Otherwise skip to Contribution Process

First off, welcome! This project was designed to help people learn about web development and working with a team. Please don't hesitate to contact me (the current maintainer of this repo) about this project. I'm here to help people learn and if I don't know the answer to your question then I'll help you find an answer.

Contribution Process

This process is a bit more formal than how your personal or school projects might be. This is meant to emulate a structure that you might encounter if you become a software developer. It might feel overly-complex and tedious, but to ensure this project endures we need to write things down. Part of the job is writing stuff down so the next person can understand what to do. Take the perspective of someone that has no clue what you've written or why you've done things. If someone can understand what and why you've done something before reading your code then that saves that person a lot of time and makes it easier to read your code.

Getting a Ticket

Take a look at the issues board and see if there's something unassigned that you'd like to work on. If you have questions or need support on what needs to be done, just ask. We will be monitoring the issues board so that you can start contributing as quickly as possible. If you're interested on working on an issue, leave a comment so that someone knows it has been taken. If you're not in the W3 committee yet, you won't be able to assign yourself to the issue. Once you have submitted your first feature, you'll be added to the W3 committee, so you can easily maintain it.

Starting Your Changes

Naming your branch

Whether you've forked the repo or are working directly on here, it helps to keep things tidy. Branches should use underscores for sections and hyphens for different words in the section. I'm partial to the following naming prefixes:

• fix_issue-number_short-description-of-issue: Fixes for bugs on the issues board. Omit issue number if there is no issue.

  e.g. fix_123_readme-wordwrap, just from the branch I know which issue number it is and what the issue roughly was

• feat_issue-number_feature-name

  e.g. feat_22_exam-bank, similar to above, we know it's a project or feature, which issue it's linked to and what the project roughly is

Please try and stick to these naming conventions. Also, try and base everything off of main. If you're working on stuff for the Angular rewrite, base your branch off ng-rewrite.

Before You Commit

Ensure code style is consistent with the rest of the repo

To ensure our code has consistent formatting and style, I've set up a few npm commands you should run before pushing up your changes. These libraries are: Prettier and ESLint

Eventually there will be some checks that will block you from getting your changes reviewed until your code is properly formatted. I may add more checks in the future. You can see the ESLint rules I've set up in eslint.config.mjs. You can find the npm commands in package.json under scripts. The commands are:

npm run lint   # Runs ESLint to check for code that breaks certain rules
npm run format # Runs Prettier to format your code

You can run them both using:

npm run pre-commit # Runs ESLint and then Prettier

If ESLint gives you errors, try and address them. Don't use eslint-disable unless there's no other way around something. If you're not sure about something just ask!

Now you're ready to commit your code!

Submitting your changes

Test your changes locally with main

Before pushing your code up, make sure you've rebased your branch off main and ensured everything still works. If everything works, you may push your code up, open a pull request and now your job is done (for now). Someone will review your code and either ask you to make changes or approve it. The process looks something like this:

git fetch # Update your local repository with any changes on remote
git rebase origin main # Update your local

Opening a pull request

Once approved, if you're submitting your code to main, it will be squashed, so write a well-written description of your changes. When the changes are squashed, your tiny commits will be lost and we'll have a clean, singular history on main. If your code is tied to an issue, add a keyword to automatically close the issue once your PR is merged in, examples below.

For a feature:

Feature: Exam Bank
closes #123

Description:
Talk about what was added and who it's for.
e.g. Added an exam bank which ..., which is intended to be used for students in CMPT courses.

Features:
* list
* of
* features

For a bug fix:

Fix: Word wrap on header in README page
closes #456

Issue(s):
Describe what the bug was.
e.g. On the README page, the typed in message "Computing Science Student Society" was wrapping on letters rather than words.

Root cause:
Explain the root cause of the issue.
e.g. Since the animation used GSAP's split by chars feature, each individual letter was its own inline-block, which means word wrapping wouldn't work since they were all separate divs.

Fix:
Describe your solution.
e.g. Added reverted the letters back to a single div using `split.revert()` once the animation has completed.

(optional) Future issues:
If you foresee your fix causing an issue in the future mention it here. 
If it's something we'll need to address then we can open another issue to address this one.