Talent-Acquisition-Platform

import Tabs from ‘@theme/Tabs’; import TabItem from ‘@theme/TabItem’;

🤝 Team Code of Conduct

:::note Private Repository This is an internal policy document for the P99Soft engineering team. This is not an open-source project. Do not share repository contents, architecture details, credentials, or business logic outside the team. :::

Scope

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

Our Expectations

- **Be respectful.** Everyone has a different background, skill set, and current 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. - 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

:::tip Check first — it’s usually already answered :::

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

When You Ask

Always include context. Use this structure:

```markdown title=”Question Template” 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:

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?"` (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 Slack channel so others can learn from the answer too.
Ask and then go offline	Stay available to answer follow-up questions promptly.
Open a duplicate issue	Comment with new information on the existing one.
Vague titles like `"Bug in jobs page"`	Specific: `"[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 where it was observed
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 Never open a GitHub issue for security vulnerabilities This exposes the problem before a fix is ready. :::

Report directly to the team lead or CTO via:

Email: 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 well.
Write a description explaining why this change was needed, not just what it does.
Link the related issue or ticket with 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 — ever.

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 a 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.
Last updated: July 2026 · Version 1.0 ~