Add CONTRIBUTING.md

Added a comprehensive contributing guide for the project, outlining how to report issues, propose features, and submit pull requests, along with guidelines for testing, documentation, and community engagement.

Author: briacdev

CONTRIBUTING.md

@@ -0,0 +1,79 @@
+# Contributing to Singularities‑AI
+
+Thank you for your interest in contributing to Singularities‑AI! We welcome contributions from the community of all skill levels. This guide explains how you can get involved, what our workflow is, and what standards we follow to keep the project healthy.
+
+## 1. Why Contribute?
+- Singularities‑AI is a **self-hosted, privacy-first** web UI for LLMs, enabling users to run models offline and control their data.  
+- By contributing, you help improve the platform for everyone — from bug fixes and documentation improvements to new features and integrations.  
+- Your work will be visible to the community, appreciated by users, and can serve as part of your portfolio.
+
+## 2. Code of Conduct
+By participating, you agree to follow our Code of Conduct. Please be respectful, constructive, and inclusive in all communications (issues, pull requests, comments). We want to maintain a welcoming environment for everyone.
+
+## 3. How to Contribute
+
+### 3.1 Reporting an Issue
+If you find a bug, unexpected behaviour, or have a feature request:  
+1. Check the existing issues in the repository first to see if it’s already reported.  
+2. If it’s new, open a new **Issue**:  
+   - Provide a clear and descriptive title.  
+   - Describe what you expected vs what actually happened.  
+   - Include steps to reproduce, environment details (OS, version, front/back end version).  
+   - Add screenshots or logs if helpful.  
+3. Be open to follow-up questions or requests for clarification from maintainers.
+
+### 3.2 Proposing a Feature or Enhancement
+- Open an issue with tag “enhancement” (or similar) describing the feature: why it matters, how it might work, what trade-offs exist.  
+- If you’re ready to work on it, mark your intention (via comment) and a maintainer can assign or discuss it with you.  
+- We encourage small, incremental enhancements rather than large monolithic changes when possible.
+
+### 3.3 Submitting a Pull Request (PR)
+1. Fork the repository and create a new branch from `main` (e.g., `feat/my-cool-feature` or `fix/issue-123`).  
+2. Write or update tests where appropriate. We value test coverage and maintainability.  
+3. Ensure code adheres to existing style conventions (coding style, linting) and that the build passes.  
+4. Update documentation if your change adds or modifies behaviour (README, docs folder, comments).  
+5. In your PR description:  
+   - Reference the issue number (e.g., “Fixes #45”).  
+   - Explain what you changed and why.  
+   - Highlight any trade-offs or side-effects.  
+6. Keep PRs small and focused. Large PRs are harder to review and slower to merge.  
+7. Respond to review feedback; maintainers may request changes before merging.
+
+## 4. Branching & Releases
+- `staging` branch is the stable version.  
+- There may be a `dev` or `next` branch for upcoming features.  
+- For urgent fixes (bugs/security) we may create hotfix branches.  
+- Each release is tagged and includes release notes summarizing changes.
+
+## 5. Testing & Quality
+- We rely on automated tests (unit/integration) to ensure stability.  
+- Run existing test suites locally before submitting changes.  
+- Ensure your changes don’t introduce regressions or degrade performance.  
+- Document any new requirements or environment variables.
+
+## 6. Documentation
+- Good documentation is as important as good code.  
+- Update README, code comments, or any docs when behaviour changes.  
+- Provide usage examples or screenshots if applicable.  
+- Fixing a typo or clarifying docs counts as a valuable contribution.
+
+## 7. Style Guidelines
+- Use consistent indentation, naming conventions, and formatting (based on existing code).  
+- Write clear commit messages: short summary (50–72 chars) + optional detailed body.  
+- Use meaningful branch names.  
+- Avoid including compiled files, secrets, or large binaries in your commits.
+
+## 8. Licensing & Ownership
+- This project is licensed under a Source‑Available Non‑Commercial Licence (see LICENSE.txt).  
+- By submitting a contribution (pull request), you agree to license your contribution under the same licence terms.  
+- Make sure you own the copyright to the code you submit (or it is appropriately licensed).
+
+## 9. Community & Communication
+- Discussions happen via Issues and Pull Requests in this repository.  
+- For larger or more interactive discussions, we may use a chat or forum (see README for details).  
+- Thanks to everyone who helps review, triage issues, or answer questions — your contributions count just as much as code.
+
+## 10. Thank You!
+Your contributions help make Singularities‑AI stronger, more reliable, and widely usable. Even a documentation improvement or typo fix is a valid contribution. Welcome aboard!
+
+**Let’s build something great together!**