Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
81 lines (55 loc) · 2.78 KB

CONTRIBUTING.md

File metadata and controls

81 lines (55 loc) · 2.78 KB

Contributing to PolicyGraph

Before You Start

Please read the README to understand the project scope and align with MVP goals. For large changes, open an issue first to discuss the approach.

Branching

Use short, kebab-case prefixes for feature branches:

  • feat/ for new features
  • fix/ for bug fixes
  • chore/ for maintenance tasks
  • docs/ for documentation updates
  • refactor/ for code refactoring

Example branch names: feat/epa-document-parser, fix/neo4j-connection, docs/api-endpoints

Commit Messages

Follow Conventional Commits format:

  • Types: feat, fix, chore, docs, refactor, test, build, ci
  • Use imperative mood for the subject line
  • Optional scope in parentheses
  • Body for rationale when needed
  • Reference issues with #

Example: feat(parser): add EPA document parsing logic

Pull Requests

One logical change per PR. Include:

  • Clear description of the change
  • Rationale for the change
  • Tests or verification notes (even if manual)
  • Documentation updates if needed
  • Confirmation no secrets were added
  • Confirmation passes local checks (placeholder)

Reviews & Merges

  • Require at least one approval
  • Squash-merge by default
  • PR title should be a Conventional Commit styled summary

Code of Conduct

This project follows a standard Code of Conduct to be added later.

License Contributions

Contributions are made under the repository's eventual license. Until then, contributions are accepted under the placeholder terms in LICENSE.

Security

Do not file security vulnerabilities in public issues. Use the private channel or email (placeholder) for security reports.

Environment File Management

Secret Handling Policy

  • Never commit actual secrets - Passwords, API keys, and sensitive values should never be committed to version control
  • Use environment files properly - Follow the established pattern for .env.example, .env.local, and .env.production
  • Local development - Use .env.local for your local environment (automatically git-ignored)
  • Production templates - Keep .env.production as a commented template only

Branch Naming for Secret-Related Changes

When working on secret handling or environment configuration:

  • Use docs/secrets-* prefix for documentation updates
  • Use chore/env-* prefix for environment file changes
  • Use security/* prefix for security-related improvements

Before Submitting Changes

  • Verify no secrets are included in the changes
  • Check that .env.local remains git-ignored
  • Ensure .env.production contains only commented keys
  • Update documentation if environment configuration changes
  • Test that the changes don't break local development setup

For detailed guidance on secret management, see the Secrets Management Runbook.