Add Contributing Guidelines for Group Collaboration

CONTRIBUTING.md

@@ -0,0 +1,55 @@
+# Contributing Guidelines
+
+### Group Information
+- Group Number: **22**
+- Members:
+  - \[E] Ethan
+  - \[G] Gleb
+  - \[S] Saleh
+  - \[T] Themis
+
+## Git Workflow and Guidelines
+
+To ensure smooth collaboration and code quality, please follow these guidelines:
+
+### Commit Messages
+**This is assessed** so please follow the conventions:
+
+- Use imperative / simple present tense for commit messages. e.g., `Add fetch cycle`, `Fix ...`, `Update`, `Delete`, etc. *NOT*: `Added`, `Fixed`, etc.
+- Keep it short (72 characters or less). If more is needed, add a blank line and then add more details. Each commit should be a small change that this is usually unnecessary (Commit often!).
+- If in any commit you worked with someone else on the same commit, e.g., live coding or pair programming, add their initial in the end in the format, `, w/ [Initial]`. E.g., `Add fetch cycle, w/ S`. Use the initials from the group information above.
+
+# Contribution Guidelines
+
+General Guideliens:
+  - NEVER USE THE MASTER BRANCH FOR CONTRIBUTIONS. Always create a new branch for your contributions. Work only on a branch.
+  - Don't merge your branch with the master branch after you finish. Create a Pull Request (PR) instead. This then is to be reviewed by at least one other team member.
+    - If working in pairs, a team member not involved in the pair should review the PR.
+  - Don't merge your PR yourself. Wait for the reviewer to merge it. You can tag the reviewer in the PR if you want.
+
+### Branch Naming Conventions
+- All lowercase.
+- Use hyphens for spaces.
+- If necessary, add grouping tokens at the beginning of the branch name. e.g., `task1/feat/advanced-scheduler`.
+
+### Workflow
+   1. Clone the repo if you haven't already.
+   2. Pull the latest changes from the remote.
+   3. Create a new branch for your work. e.g., `git checkout -b task1/feat/advanced-scheduler`.
+   3. Make your changes. (Commit often)
+   4. Push your branch to the remote.
+   5. Once all is done, head to GitLab and create a new Pull Request.
+
+## Style Guidelines
+To ensure code consistency, please follow the PintOS coding styling. You can search for whatever you are about to do and see how it is done in the PintOS codebase. If you cannot find anything or are unsure, follow the [GNU Coding Standards](https://www.gnu.org/prep/standards/html_node/index.html).
+
+Write clean, readable, and maintainable code. This includes:
+  - Use meaningful variable and function names.
+  - Use comments to explain complex code.
+  - Use whitespace to separate logical sections of code.
+  - Use consistent naming conventions, follow those of PintOS.
+
+Also Keep in mind:
+  - Never reformat the entire file/codebase!
+  - Make sure not to add to git any files related to your operating system or IDE. 
+  - Wrap lines at 80 characters.