Contribution guidelines proposal

[tregubovav-dev]

I want to offer the Contributing Guidelines draft for the discussion.

Contributing Guidelines

Thank you for contributing to TaurusTLS! As our team grows, these guidelines help ensure seamless collaboration, protect codebase stability, and prevent collisions. We appreciate any suggestions that help make project development and maintenance enjoyable and smooth.

---

1. Branch Management & Commit Policy

• No direct commits to main: The main branch represents stable release states. Direct pushes to main are disabled.
• Workflow: All bug fixes, enhancements, and features must be introduced via topic branches merged into dev, or via pull requests from external forks targeting dev.

---

2. Pull Request (PR) Workflow

To maintain code quality and keep everyone aligned:

1. Review Required: Every PR must undergo review prior to merging.
2. Approval: At least one active maintainer must approve the PR.
3. Resolve Conversations: All comments, questions, or requested modifications must be resolved before the PR can be merged.

---

3. Bugs and Issues Resolution

To keep issue tracking efficient and transparent across the project:

1. Issue Templates:
   • Please use our provided templates when creating a new issue:
     • Bug Report: For reporting bugs or unexpected behavior.
     • Enhancement: For proposing new features or improvements.
   • Include essential environment details (Delphi version, FPC version, OS, TaurusTLS version) and reproduction steps where applicable.
2. Issue Assignment & Ownership:
   • Work on an issue is owned once it is assigned to a developer (either voluntarily or following a quick team discussion).
   • Do not start working on an unassigned issue without confirming ownership first to avoid duplicate work.
3. Linking PRs:
   • Reference the issue in your PR description using standard GitHub keywords (e.g., Fixes #123 or Closes #123) so the issue closes automatically upon merging into dev.
4. Security Vulnerabilities:
   • For critical security flaws (e.g., severe TLS protocol bugs or memory leaks), contact maintainers privately via instant message before posting public issue details.

---

4. Unit Testing Guidelines

We aim to steadily improve our test coverage without stalling active development:

• Legacy Code: Legacy areas currently lack full unit test coverage. Adding tests for legacy code is highly appreciated, but not required for PR approval.
• New & Refactored Code: New features or refactored logic should include accompanying unit tests whenever feasible.
• Test Framework Preference:
  • Delphi: Use the latest official release of DUnitX.

    Note: Avoid using the bundled DUnitX shipped with the Delphi IDE, as older Delphi installations contain outdated builds.

  • Free Pascal (FPC): Developers working with FPC may submit tests written using FPTest or FPCUnit.

---

5. Developer Communication

To minimize back-and-forth email delays and keep PR comments focused strictly on code:

• Real-time Collaboration: We use instant messaging (Telegram / Google Chat / Discord) for quick queries, technical syncs, and architecture decisions.
• Issues & PRs: Use GitHub Issues for bug tracking and feature proposals, reserving PR inline comments for code-specific review feedback.