chore(docs): update contributing and simplify PR template

Author: zenlex

.github/PULL_REQUEST_TEMPLATE.md

@@ -3,69 +3,12 @@
 - Fixes: <!-- #(issue) -->
 - Closes: <!-- #(issue) -->
 
-## Checklist
-
-- [ ] This PR conforms to the guidelines in [CONTRIBUTING.md](../CONTRIBUTING.md)
-  - [ ] It has a descriptive title
-  - [ ] My commits conform to the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) specification
-- [ ] This PR is not a duplicate of a similar PR ([how to search issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/filtering-and-searching-issues-and-pull-requests) for similar/duplicate PRs, which this is not
-- [ ] This PR targets the `dev` branch
-- [ ] I ran the pre-commit hooks or `npm test && npm lint && npm test:e2e` and all tests pass
-
-<hr>
-
 ## Description
 
 <!--
 Please include a summary of the change and which issue it addresses. Include the motivation for the changes and any additional context.
 -->
 
-## Type of Change
-
-<!--
-Please delete options that are not relevant.
--->
-
-- [ ] Bug fix (non-breaking change which fixes an issue)
-- [ ] New feature (non-breaking change which adds functionality)
-- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
-- [ ] Documentation update
-- [ ] Code cleanliness (removal of unnecessary comments or debug logs)
-
-## How Has This Been Tested?
-
-<!--
-Please describe the tests that you ran to verify your changes.
-- Please Provide instructions so we can reproduce the scenarios.
-- Please List any relevant details for your test configuration.
-
-    - [ ] Test A
-    - [ ] Test B
--->
-<!--
-**Test Configuration** (Optional):
-
-- Firmware version:
-    -  If you know the version of any specific software you used, list it here. If unsure, you can leave it blank.
-- Hardware:
-    -  Mention your computer or device model if your changes are hardware-dependent. If not, it's okay to skip.
-- Toolchain:
-    - This refers to the set of programming tools you used. For beginners, it could be the IDE (Integrated Development Environment) like Visual Studio Code.
-- SDK:
-    - Mention any specific Software Development Kit versions you used. If you didn't use any, no need to include it.
--->
-
-## Microservices and API Integration
-
-- [ ] If applicable, my changes are compatible with the project's microservices architecture and API gateway integration requirements.
-
-## Checklist:
-
-- [ ] My code follows the style guidelines of this project
-- [ ] I have made corresponding changes to the documentation
-- [ ] I have removed all unnecessary comments and debug log statements
-- [ ] I have linked this PR to its corresponding issue
-
 ## Screenshots (if appropriate):
 
 Please review and suggest any further insights, improvements, or modifications needed.

CONTRIBUTING.md

@@ -78,6 +78,8 @@ These prefixes are among the most commonly used in branch naming conventions:
 Check out this resources for more details
 [Best Practices to Follow](https://phoenixnap.com/kb/git-branch-name-convention)
 
+_While working in your own fork you are welcome to work off your own `main` branch and label pull requests descriptively instead if preferred_
+
 ## Pre-commit Setup
 
 To set up pre-commit hooks for your project, you'll need to install the pre-commit package manager.
@@ -94,8 +96,6 @@ Our project uses GitHub Actions for continuous integration (CI) and deployment t
 
 ### Deploy to GitHub Pages Workflow
 
-**Trigger**: This workflow is triggered on pushes to the dev branch and can also be run manually via GitHub's Actions tab.
-
 **Purpose**: It's designed to build the project using Astro and deploy it to GitHub Pages. This ensures that our development progress is automatically compiled and made visible for testing and preview.
 
 Steps:
@@ -104,13 +104,13 @@ Steps:
 
 - **Build and Upload**: The site is built using Astro, and the output is prepared for deployment.
 
-- **Deployment**: The built site is deployed to GitHub Pages.
+- **Deployment**: The built site is deployed to GitHub Pages. It will be deployed when commits are tagged for relase with semver.
 
 **Contributors should target their feature branches towards the dev branch for any site updates or changes. This branch is our staging area for the website.**
 
 ### Frontend CI Workflow
 
-**Trigger**: This workflow is activated on push or pull request events for the dev and prod branches. It supports manual triggers as well.
+**Trigger**: This workflow is activated on push or pull request events for the prod branch. It supports manual triggers as well.
 
 **Purpose**: To ensure that frontend changes (e.g., style updates, JavaScript modifications) do not break the build. It helps maintain the integrity of our codebase.
 
@@ -157,11 +157,11 @@ Please see the [Conventional Commits website](https://www.conventionalcommits.or
 
 1. Fork the Project
 2. Clone your Fork
-3. Create your Feature Branch (`git checkout -b feature/AmazingFeature`)
+3. Create your Feature Branch if desired (`git checkout -b feature/AmazingFeature`)
 4. Commit your Changes (`git commit -m 'feat: Add some AmazingFeature'`)
    **[see above commit prefixes](#conventional-commits)**
 5. Push to the Branch (`git push origin feature/AmazingFeature`)
-6. Open a Pull Request
+6. Open a Pull Request against the `tulsawebdevs/website:prod` branch
 
 - Ensure any install or build dependencies are removed before the end of the layer when doing a build.
 - Update the README.md with details of changes to the interface, including new environment variables, exposed ports, useful file locations, and container parameters.