UniTrack V3

Table of Contents

• Overview
• Getting Started
• Contributing
  • Commit Messages
  • Branch Names
  • Pull Requests
    • Title
    • Description
    • Example Pull Request
  • Open Source
• Developing Team

Overview

This project was initiated for Coding Fest 2023 by Udit Samant, Jennifer Tan, Devanshi Mirchandani, and Parth Bhargava. The purpose of UniTrack is to present a university services platform with a better user experience, mainly targeting degree planning, unit selection, and time table selection.

After two iterations of technical stacks for this project we have settled on React, Next.Js, and Vercel

We welcome any collaboration and contributions from the public to this project, please refer to the open source contribution section.

We would like to acknowledge Antriksh Dhand in his contribution as the original ideator of this project

Getting Started / Installation

SSH authentication is recommended, visit this link for more information.

1. Clone the repo using `git clone --recurse-submodules git@github.com:USYDUniTrack/unitrack_v3.git
2. Run development server based on your preferred package manager.

NOTE: Maintainer and DB-Codeowner/DB-Contributor Developers please use vercel dev

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev
# or
vercel dev #strictly for maintainers and testing postgres db

Open http://localhost:3000 with your browser to see the result.

Contributing

Read the guidelines below to write good commit messages, branch names, and make pull requests that follow the conventions we will be using throughout the project.

Issues

We welcome contribution to this project. Changes to this repository will be received on a issue assigned basis. To contribute...

• [ ] Find an issue that is unassigned, unmarked, or contains the help wanted label.
• [ ] Change code and create a pull request closing the issue - see link. After which a maintainer will assign you to the issue (If this issue is large in complexity and you want to be assigned to the issue, comment on the issue).

Commit Messages

• Capitalise the subject line.
• Do not end with a period.
• Use imperative mood, i.e. instead of "Added ..." write "Add ...".
• Keep messages logical and relevant, do not write things like "Please work" or "I hate frontend". To help decide the extent of this, imagine trying to access a point in the project 2 weeks ago, it would be better to have something like "Add CSS for Navbar template" or , so that we know from a glance what the commit is for.
• For more detailed messages, use git commit -m <title> -m <description>, however short and concise is still preferred.

Branch Names

Make a branch using git checkout -b <branch_name>.

• Names fall under one of 4 categories
  • Minor Feature: minor-featureName
  • Major Feature: major-featureName
  • Patch: patch-patchName
  • Miscellaneous: name
    • For example documentation for changing the README, or adding another markdown

patch: a non API breaking change to the codebase - anyone that uses your code will not need to be concerned with the changes you pushed. minor: a minor API change to the codebase - anyone that uses your code will need to slightly modify implementation of their code. major: a major API change to the codebase - generally breaks code, wherever used, and will need significant modification.

Examples

• Adding comments - patch
• Image sizing changes (doesn't effect other code) - patch
• Changing div css - minor
• Changing div ordering - minor
• Changing server API endpoints - major as it breaks other code.

Pull Requests

Summarised from this article.

Title

• Short and descriptive summary
• Start with corresponding ticket/story id (e.g. from Jira, GitHub issue)
• Should be capitalized and written in imperative present tense
• Do not end with period
• Suggested format: # PR description

Description

• Closing keyword with issue number - see link (e.g. Closes #0).
• Separated with a blank line from the subject
• Explain changes and justify
• Separate different issues into different paragraphs (capitalising each paragraph)
• We recommend using screenshots over long descriptions (A simple before and after will do)
• If the description is longer than a paragraph include a TLDR: one-liner as the first line

Example Pull Request

TLDR: (Necessary for longer PRs) this PR defines PR message syntax.
resolves/closes/fixes #ISSUE_NO (, resolves/closes/fixes #ISSUE_NO2 (, ...))

This pull request is part of the work to make it easier for people to contribute to naming convention guides.

To achieve this, we have:
- Found an issue
- Made a PR
- Made clear the changes introduced
- Included images

Open Source

Follow the steps below to suggest a patch or a feature for this project. For information on naming conventions for pull requests or commits, read the rest of the contributing section above.

1. Fork the repo
2. Create your Feature Branch: git checkout -b <branch_name>
3. Commit your Changes
4. Push to the Branch: git push origin <branch_name>
5. Open a Pull Request

Developing Team

• Parth Bhargava
• Devanshi Mirchandani
• Jennifer Tan
• Udit Samant
• Antriksh Dhand