Skip to content

Contributing

Jump to bottom
DHANUSH G edited this page Mar 4, 2026 · 1 revision

🤝 Contributing Guide

Back to Home | API-Reference | GSoC-Project-Ideas

We welcome all contributions — whether it's fixing a bug, adding a feature, improving documentation, or writing tests. This guide explains how to contribute effectively.

📋 Table of Contents

📜 Code of Conduct

This project follows an open, respectful contributor environment. All participants are expected to:

  • Be respectful and constructive in all communications
  • Welcome newcomers and help them get started
  • Focus on the issue, not the person
  • Accept that different viewpoints have merit

🚀 Getting Started

  1. Fork the repository on GitHub
  2. Clone your fork locally: 
    git clone https://github.com/YOUR_USERNAME/AI-Powered-Security-Monitoring-Threat-Detection-Platform.git
cd AI-Powered-Security-Monitoring-Threat-Detection-Platform
  3. Set up the development environment: See Setup-Guide
  4. Create a branch for your work: 
    git checkout -b feature/your-feature-name
# or
git checkout -b fix/issue-number-description

🛠️ Types of Contributions

🐛 Bug Fixes

  • Check existing Issues first
  • Reference the issue number in your PR: Fixes #42
  • Add a regression test to prevent recurrence

✨ New Features

  • Open an issue first to discuss the feature before implementing
  • Check the GSoC-Project-Ideas page for major feature ideas
  • Keep features focused and well-scoped

📝 Documentation

  • Fix typos, clarify wording, add examples
  • Update wiki pages when behavior changes
  • Ensure code comments stay accurate

🧪 Tests

  • Add unit tests for any new functionality
  • Improve test coverage for existing code
  • See backend/tests/ for examples

🎨 Frontend / UI

  • UI improvements to the Next.js dashboard
  • New chart types or 3D visualization features
  • Accessibility improvements

🔄 Development Workflow

# 1. Create a feature branch
git checkout -b feature/websocket-alerts

# 2. Make your changes
# ... edit files ...

# 3. Run tests to ensure nothing is broken
export PYTHONPATH=.
pytest backend/tests/ -v

# 4. Stage and commit with a clear message
git add .
git commit -m "feat: add WebSocket endpoint for real-time alerts"

# 5. Push to your fork
git push origin feature/websocket-alerts

# 6. Open a Pull Request on GitHub

💯 Coding Standards

Python (Backend)

  • Follow PEP 8 style guide
  • Use type hints for all function signatures
  • Docstrings for all public functions and classes
  • Maximum line length: 100 characters
  • Use snake_case for variables and functions
# Good
def get_logs(skip: int = 0, limit: int = 100) -> list[Log]:
    """Retrieve paginated log entries from the database."""
    return db.query(Log).offset(skip).limit(limit).all()

# Avoid
def getLogs(s, l):
    return db.query(Log).offset(s).limit(l).all()

TypeScript / JavaScript (Frontend)

  • Follow the existing ESLint configuration
  • Use functional components with hooks
  • Prefer named exports
  • Use camelCase for variables, PascalCase for components

Commit Message Format

Follow Conventional Commits:

<type>(<scope>): <short description>

[optional body]

[optional footer: Fixes #issue]
Type When to use
feat New feature
fix Bug fix
docs Documentation only
test Adding/updating tests
refactor Code change without feature/fix
chore Maintenance tasks
ci CI/CD changes

🧪 Testing Requirements

All PRs must include appropriate tests:

Contribution Type Test Requirement
New API endpoint Unit tests for success + error cases
Bug fix Regression test
ML model change Prediction accuracy test
Frontend feature Not required (manual review)

Running Tests

export PYTHONPATH=.

# All tests
pytest backend/tests/ -v

# With coverage report
pytest backend/tests/ --cov=backend --cov-report=html

# Only a specific module
pytest backend/tests/test_logs.py -v

Minimum requirements:

  • All existing tests must pass
  • New code should maintain or improve coverage
  • Tests must be deterministic (no flaky tests)

📫 Pull Request Guidelines

Before Submitting

  • All tests pass locally
  • Code follows project style guidelines
  • Documentation updated if needed
  • Commit messages are clear and follow conventions
  • Branch is up-to-date with main

PR Description Template

## Summary
Brief description of what this PR does.

## Changes Made
- Added X
- Fixed Y
- Updated Z

## Testing
- [ ] Unit tests added/updated
- [ ] All tests pass: `pytest backend/tests/ -v`

## Related Issues
Fixes #<issue-number>

Review Process

  1. CI pipeline must pass (GitHub Actions)
  2. At least one reviewer approval required
  3. Address all review comments
  4. Squash commits if requested

🐛 Issue Reporting

Bug Reports

Use the following template:

**Describe the bug**
A clear description of what the bug is.

**Steps to Reproduce**
1. Run `...`
2. Call endpoint `...`
3. See error

**Expected Behavior**
What you expected to happen.

**Actual Behavior**
What actually happened.

**Environment**
- OS: [e.g., Ubuntu 22.04]
- Python: [e.g., 3.10.12]
- Node.js: [e.g., 18.17.0]

Feature Requests

  • Check the GSoC-Project-Ideas page for existing roadmap items
  • Open an issue with the enhancement label
  • Describe the use case and expected behavior

🌟 Recognition

All contributors are recognized in the project. Significant contributions may be listed in the README and release notes.

Thank you for helping make this project better!

Back to Home | API-Reference | GSoC-Project-Ideas

Clone this wiki locally