# 🤝 Team Code of Conduct

> **This is a private, internal project.**  
> This document governs how the P99Soft engineering team communicates, collaborates, and resolves issues within this repository.

---

## Scope

This Code of Conduct applies to all interactions within this private repository — including code reviews, pull requests, issues, comments, internal discussions, and any related communication channels (Slack, email, standups) directly tied to this project.

---

## Our Expectations

### ✅ How We Work Together

- **Be respectful.** Everyone on this team has a different background, skill set, and workload. Treat each other accordingly.
- **Be constructive.** When reviewing code or raising concerns, focus on the work — not the person.
- **Be patient.** Not everyone has the same context on every part of the codebase.
- **Be direct and honest.** If something is wrong, raise it clearly and professionally — silence doesn't help anyone.
- **Give credit.** If someone solved the problem or pointed you in the right direction, acknowledge it.
- **Default to documentation.** If you figure something out, write it down in `/docs` so the next person doesn't have to ask.

### ❌ What We Don't Accept

- Personal attacks, condescending remarks, or dismissive language in any review or discussion.
- Belittling teammates for asking questions or being unfamiliar with a part of the codebase.
- Passive-aggressive comments in code review (e.g., "obviously", "clearly", "just do it this way").
- Ignoring or stonewalling feedback from other team members.
- Sharing project code, architecture details, credentials, or business logic outside the team.
- Unilateral changes to shared infrastructure, production configs, or core architecture without team discussion.

---

## 📬 How to Ask Questions — Team Standards

Good questions save everyone time. Follow these norms before pinging a colleague.

### Before You Ask

1. **Check the docs first.** Look in `/docs`, the README, `ARCHITECTURE.md`, or search through closed PRs and issues.
2. **Read the error message fully.** Copy the exact error — it usually has everything you need.
3. **Try to isolate it.** Can you reproduce it consistently? In what conditions?
4. **Check recent PRs.** The answer may already be in a recent merge.

### When You Ask

Always include context. Structure it like this:

```
What I'm trying to do:
[State the goal clearly]

What I expected:
[Describe the expected behaviour]

What actually happened:
[Paste the exact error, log output, or unexpected behaviour]

Steps to reproduce:
1. ...
2. ...
3. ...

Environment:
- Branch:
- OS / Docker version:
- Node / Python version:
```

### Ask vs. Don't Ask

| ❌ Don't do this | ✅ Do this instead |
|---|---|
| `"It's broken, can you fix it?"` | Describe what's broken with the exact error and reproduction steps. |
| `"Why did you write it this way?"` (in a hostile tone) | `"I don't fully understand this pattern — can you explain the reasoning?"` |
| DM someone for a question only you benefit from | Ask in the relevant project Slack channel so others can see the answer. |
| Ask and then go offline | Be available to answer follow-ups promptly. |
| Open a duplicate issue | Comment with new information on the existing one. |
| Vague titles like `"Bug in jobs page"` | Specific titles like `"[Jobs] Filter resets on pagination when role is Recruiter"` |

---

## 🐛 Reporting Issues

### Bugs

Create an issue in this repository using the **Bug Report** template. Include:
- The branch and environment you observed it on
- Exact error message or unexpected behaviour
- Reproduction steps
- Who is impacted (role, tenant, environment)

### Improvements / Feature Work

Open an issue or raise it in the relevant sprint planning meeting. Describe **the problem you're solving**, not just the feature you want — it leads to better solutions.

### Security Issues

:::caution Private — do not open a GitHub issue
:::

**Never create a GitHub issue for security vulnerabilities.** This exposes the problem before a fix is ready.

Instead, report directly to the team lead or CTO via:
- **Email:** [admin@p99soft.com](mailto:admin@p99soft.com)
- **Direct Slack DM** to the responsible maintainer

Include: what you found, how to reproduce it, and potential blast radius.

### Conduct Violations

Report privately to the engineering lead or HR. All reports are handled confidentially.

---

## 🔁 Pull Request Standards

### As the Author

- Keep PRs **small and focused** — one concern per PR. Large PRs don't get reviewed properly.
- Write a clear description with **why** this change was needed, not just what it does.
- Link the related issue or ticket using `Closes #<issue>` or `Related to #<issue>`.
- Self-review your diff in the **Files Changed** tab before requesting a review.
- Do **not** merge your own PRs. Every PR needs at least one approval.
- Do **not** force-push to `main`, `staging`, or any shared branch.
- Do **not** commit secrets, `.env` files, or credentials.

### As a Reviewer

- Be timely. Aim to review within **one business day**. Blocked PRs block everyone downstream.
- Suggest, don't command. Prefix non-blocking feedback:
  - `[nit]` — minor style preference, not blocking
  - `[suggestion]` — worth considering, not required
  - `[blocker]` — must be resolved before merging
  - `[question]` — genuinely asking, not demanding change
- Approve when the PR is **good enough to ship**, not only when it's perfect.
- If you have concerns, raise them clearly — don't just silently request changes with no explanation.

---

## ⚖️ Enforcement

Conduct violations will be handled by the engineering lead in consultation with HR where appropriate.

| Severity | Example | Action |
|---|---|---|
| **Minor** | Occasional dismissive language in review | Private conversation and written note. |
| **Moderate** | Repeated disrespect or ignoring team norms |  |
| **Serious** | Harassment, data breach, leaking proprietary code |  |

---

*This is an internal document for the P99Soft engineering team. It is not a public or open-source policy.*  
*Last updated: July 2026 · Version 1.0*