Contributing to DeediX Technologies

Thank you for your interest in contributing to a DeediX Technologies open-source project. We welcome contributions of all kinds — code, documentation, bug reports, design feedback, and ideas.

Please take a few minutes to read this guide before you open an issue or pull request. It helps us review and merge contributions faster.

---

Table of Contents

1. Code of Conduct
2. Getting Started
3. How to Contribute
   • Reporting Bugs
   • Requesting Features
   • Submitting a Pull Request
4. Development Guidelines
5. Commit Message Convention
6. Review Process
7. Getting Help

---

Code of Conduct

All contributors are expected to follow our Code of Conduct. By participating you agree to uphold these standards. Violations can be reported to hello@deedixtech.com.

---

Getting Started

1. Fork the repository to your own GitHub account.
2. Clone your fork locally:

   git clone https://github.com/<your-username>/<repo-name>.git
   cd <repo-name>

3. Install dependencies as described in the project's README.md.
4. Create a branch for your change (see branch naming below).
5. Make your changes, then open a pull request against the main branch.

---

How to Contribute

Reporting Bugs

Before opening a bug report, please:

• Search existing Issues to see if it has already been reported.
• Confirm you are using the latest version of the project.

When opening an issue, include:

• A clear, descriptive title.
• Steps to reproduce the problem.
• What you expected to happen and what actually happened.
• Environment details (OS, runtime version, browser, etc.).
• Any relevant logs, screenshots, or error messages.

Requesting Features

We use GitHub Discussions for feature proposals. Before opening one:

• Search existing discussions to avoid duplicates.
• Describe the problem you are trying to solve, not just the solution you have in mind.
• Explain who would benefit and how.

For smaller improvements, you can open an issue directly with the enhancement label.

Submitting a Pull Request

1. Branch naming — use a descriptive, lowercase branch name:

   • feat/short-description — new feature
   • fix/short-description — bug fix
   • docs/short-description — documentation only
   • chore/short-description — tooling, dependencies, housekeeping

2. Keep changes focused — one concern per PR. Avoid mixing unrelated fixes or refactors.

3. Write or update tests where applicable.

4. Update documentation if your change affects public behaviour, APIs, or configuration.

5. Check for errors before pushing:

   # Example — adapt to the project's tooling
   npm run lint
   npm test

6. Open the PR against main with a clear title and description. Reference any related issue with Closes #<issue-number>.

7. Do not force-push to a PR branch after review has started — it makes re-review harder.

---

Development Guidelines

• Follow the coding style and conventions already present in the project.
• Prefer clarity over cleverness — code is read far more often than it is written.
• Keep functions and modules small and focused on a single responsibility.
• Avoid introducing new dependencies without prior discussion in an issue or Discussion.
• Sensitive data (credentials, tokens, PII) must never be committed — use environment variables.

---

Commit Message Convention

We follow Conventional Commits:

<type>(optional scope): short description

Optional longer body explaining the why, not the what.

Optional footer: Closes #123

Types: feat, fix, docs, style, refactor, test, chore, perf

Examples:

feat(auth): add GitHub OAuth login
fix(api): handle empty response from external service
docs: update installation instructions in README

Commits that do not follow this format may be squashed or edited before merge.

---

Review Process

• All pull requests require at least one approving review from a maintainer before merging.
• Reviewers aim to respond within 48 hours on business days.
• We may request changes, ask clarifying questions, or suggest alternatives — this is normal and not a rejection.
• Once approved, a maintainer will merge the PR. Do not merge your own PR without explicit permission.
• PRs that are inactive for 30 days without a response to review comments will be closed. You are welcome to reopen them.

---

Getting Help

• Questions about using the project → open a GitHub Discussion in the relevant repo.
• Questions about contributing → comment on the relevant issue or PR.
• Everything else → hello@deedixtech.com

We appreciate every contribution, no matter the size. Thank you for helping build tools that work for everyone.

---

DeediX Technologies — deedixtech.com