Create CONTRIBUTING.md

CONTRIBUTING.md

@@ -0,0 +1,125 @@
+# Contributing to This Repository
+
+We welcome pull requests, but only if they meet the project's quality and design standards. Follow the process below precisely to avoid wasting time—yours or ours.
+
+## Prerequisites
+
+- Familiarity with Git and GitHub (basic commands, branching, forking, etc.)
+- A functioning development environment
+- Node.js, Python, or other relevant runtime/tools installed (check the `README.md`)
+
+## Fork & Clone
+
+1. **Fork the repository** using the GitHub UI.
+2. **Clone your fork** locally:
+   ```bash
+   git clone https://github.com/your-username/BayesBond.git
+   cd your-fork
+
+3. **Add the upstream remote**:
+
+   ```bash
+   git remote add upstream https://github.com/BayesBond/BayesBond.git
+   ```
+
+## Create a New Branch
+
+Never work on `main` or `master`.
+
+```bash
+git checkout -b fix/brief-but-specific-description
+```
+
+Use a clear, descriptive branch name. Avoid vague names like `patch-1`.
+
+## Stay Updated
+
+Before you start, make sure your fork is up to date:
+
+```bash
+git fetch upstream
+git checkout main
+git merge upstream/main
+```
+
+Then rebase your feature branch if needed:
+
+```bash
+git checkout fix/your-feature
+git rebase main
+```
+
+## Make Atomic Commits
+
+Each commit should represent a single logical change. Follow this format:
+
+```text
+type(scope): concise description
+
+body explaining what and why, if necessary
+```
+
+Example:
+
+```text
+fix(api): handle 500 error on invalid payload
+```
+
+Types include: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`.
+
+## Test Everything
+
+If the project has tests, run them. If it doesn’t, write some. Do **not** submit code that hasn't been tested.
+
+```bash
+# Example for Node.js
+npm test
+```
+
+No exceptions. If you don't validate your changes, your PR will be closed.
+
+## Lint & Format
+
+Ensure code matches the project style. If the repo uses a linter or formatter, run them:
+
+```bash
+npm run lint
+npm run format
+```
+
+Or whatever command is defined in the repo.
+
+## Write a Good Pull Request
+
+When opening a pull request:
+
+* **Title**: Describe what the PR does, clearly and specifically.
+* **Description**: Explain the context. Link related issues (use `Fixes #123` if applicable).
+* **Checklist**:
+
+  * [ ] My code is clean and follows the style guide
+  * [ ] I’ve added or updated tests
+  * [ ] I’ve run all tests and they pass
+  * [ ] I’ve documented my changes (if necessary)
+
+## Code Review Process
+
+* PRs are reviewed by maintainers or core contributors.
+* If feedback is given, respond and push updates. Do **not** open new PRs for changes to an existing one.
+* PRs that are incomplete, sloppy, or violate the above will be closed.
+
+## Don't Do This
+
+* Don’t commit directly to `main`
+* Don’t submit multiple unrelated changes in a single PR
+* Don’t ignore CI/test failures
+* Don’t expect hand-holding—read the docs and the source first
+
+## Security Issues
+
+Do **not** open public issues for security vulnerabilities. Email the development team instead.
+
+## License
+
+By contributing, you agree that your code will be licensed under the same license as the rest of the project.
+