Thank you for considering contributing to the PhoenixRooivalk project! We welcome contributions from everyone. Here are some guidelines to help you get started.
If you find a bug, please create an issue on GitHub with the following information:
- A clear and descriptive title.
- A description of the steps to reproduce the bug.
- Any relevant screenshots or error messages.
- Your environment (operating system, browser, etc.).
We welcome new ideas and feature requests. If you have an idea for a new feature, please create an issue on GitHub with the following information:
- A clear and descriptive title.
- A detailed description of the feature and how it would benefit the project.
- Any relevant examples or mockups.
If you would like to contribute code to the project, follow these steps:
-
Fork the repository: Click the "Fork" button at the top of the repository page to create a copy of the repository in your GitHub account.
-
Clone the repository: Clone your forked repository to your local machine.
git clone https://github.com/yourusername/PhoenixRooivalk.git cd PhoenixRooivalk -
Create a branch from
dev: Always branch from thedevbranch.git checkout dev git pull origin dev git checkout -b feature/my-new-feature
-
Make your changes: Make your changes to the codebase.
-
Commit your changes: Use conventional commits.
git add . git commit -m "feat: add new feature description"
-
Push your changes: Push your changes to your forked repository.
git push origin feature/my-new-feature
-
Create a pull request targeting
dev: Go to the original repository on GitHub and create a pull request from your branch intodev(notmain).
We follow a feature -> dev -> main branching workflow:
main: Production-ready code. Protected with required reviews.dev: Integration branch. All feature PRs targetdev.- Feature branches: Short-lived branches for individual changes.
All PRs must target dev, never main directly. Merges from dev to
main happen when dev is stable and ready for release.
For the full branching strategy, see docs/branching-strategy.md.
Please ensure your code adheres to the following style guidelines:
- Use consistent indentation (e.g., 2 spaces for JavaScript, 4 spaces for Python).
- Write clear, descriptive comments where necessary.
- Ensure your code is well-documented and easy to read.
The project uses two canonical width standards:
| Context | Max Width | Side Padding | Use Case |
|---|---|---|---|
| General containers | 1440px (--pr-container-max) |
5% |
Marketing pages, dashboards, wide layouts |
| Documentation content | 850px (--pr-content-width) |
5% |
Long-form reading content (docs, articles) |
Documentation pages intentionally use a narrower 850px max-width instead of
the standard 1440px. This is because:
- Optimal line length: 50-75 characters per line is ideal for readability
- Reduced eye strain: Shorter lines reduce horizontal eye movement
- Better comprehension: Studies show narrower text columns improve reading comprehension
All layouts should follow mobile-first responsive design:
| Breakpoint | Width | Target |
|---|---|---|
| Mobile | <600px |
Small phones, full-width content |
| Tablet | 600px - 899px |
Tablets, intermediate width |
| Desktop | ≥900px |
Full content width applies |
/* General containers */
--pr-container-max: 1440px;
/* Documentation-specific */
--pr-content-width: 850px;
--pr-content-padding: 5%;When creating new layouts, use these variables rather than hard-coded values to maintain consistency across the project.
Please note that this project is governed by a Code of Conduct. By participating, you are expected to adhere to this code.
If you have any questions or need further assistance, please contact:
Jurie Smit
PhoenixVC
smit.jurie@gmail.com