patch: update dependencies, improve setup configuration, and add Wind…

.github/CODEOWNERS

@@ -0,0 +1,17 @@
+# These owners will be the default owners for everything in
+# the repo. Unless a later match takes precedence,
+# @umerfarok will be requested for review when someone 
+# opens a pull request.
+*       @umerfarok
+
+# Network monitoring core
+/networkmonitor/monitor.py @umerfarok
+/networkmonitor/npcap_helper.py @umerfarok
+
+# Web interface
+/networkmonitor/web/ @umerfarok
+
+# Build and deployment
+/.github/workflows/ @umerfarok
+/build.py @umerfarok
+/installer.nsi @umerfarok

.github/CODEOWNERS.md

@@ -0,0 +1,42 @@
+# Code Owners Documentation
+
+This document explains the code ownership structure of the NetworkMonitor project.
+
+## Overview
+
+The CODEOWNERS file is used to automatically request reviews from the appropriate team members when a pull request is opened.
+
+## Current Ownership Structure
+
+### Core Components
+- **Network Monitoring Core** (@umerfarok)
+  - `/networkmonitor/monitor.py`
+  - `/networkmonitor/npcap_helper.py`
+
+### Web Interface
+- **Frontend Components** (@umerfarok)
+  - `/networkmonitor/web/`
+
+### Build & Deployment
+- **Build System** (@umerfarok)
+  - `/build.py`
+  - `/installer.nsi`
+  - `/.github/workflows/`
+
+## Review Process
+
+1. When a pull request is opened, GitHub automatically requests reviews from the appropriate code owners.
+2. At least one approval from a code owner is required to merge changes.
+3. Code owners should review changes within their area of responsibility within 3 business days.
+
+## Becoming a Code Owner
+
+To become a code owner:
+1. Demonstrate expertise in the relevant area through contributions
+2. Request ownership by opening an issue
+3. Get approval from existing code owners
+
+## Contact
+
+For questions about code ownership, contact:
+- Umer Farooq (@umerfarok)

.github/CONTRIBUTING.md

@@ -0,0 +1,112 @@
+# Contributing to NetworkMonitor
+
+Thank you for your interest in contributing to NetworkMonitor! We welcome contributions from everyone.
+
+## Getting Started
+
+1. Fork the repository
+2. Clone your fork:
+   ```bash
+   git clone https://github.com/your-username/networkmonitor.git
+   ```
+3. Create a virtual environment and install dependencies:
+   ```bash
+   python -m venv venv
+   source venv/bin/activate  # or `venv\Scripts\activate` on Windows
+   pip install -r requirements.txt
+   pip install -r requirements-build.txt
+   ```
+
+## Development Process
+
+1. Create a branch for your changes:
+   ```bash
+   git checkout -b feature/your-feature-name
+   ```
+
+2. Make your changes, following our coding standards:
+   - Follow PEP 8 style guide
+   - Write descriptive commit messages
+   - Include tests for new features
+   - Update documentation as needed
+
+3. Test your changes:
+   ```bash
+   python -m pytest tests/
+   ```
+
+4. Push your changes and create a pull request:
+   ```bash
+   git push origin feature/your-feature-name
+   ```
+
+## Pull Request Guidelines
+
+1. Fill out the PR template completely
+2. Include tests for new features
+3. Update documentation if needed
+4. Ensure CI passes
+5. Request review from appropriate code owners
+
+## Code Style
+
+- Follow PEP 8 conventions
+- Use type hints where possible
+- Document public functions and classes
+- Keep functions focused and concise
+- Write descriptive variable names
+
+## Commit Messages
+
+Format:
+```
+type(scope): description
+
+[optional body]
+[optional footer]
+```
+
+Types:
+- feat: New feature
+- fix: Bug fix
+- docs: Documentation only
+- style: Code style changes
+- refactor: Code changes that neither fix bugs nor add features
+- test: Adding or modifying tests
+- chore: Maintenance tasks
+
+Example:
+```
+feat(monitor): add packet filtering by protocol
+
+Added support for filtering network packets by protocol type.
+Implements #123
+```
+
+## Documentation
+
+- Update README.md for user-facing changes
+- Update DEVELOPER.md for development changes
+- Add comments for complex code sections
+- Include docstrings for public APIs
+
+## Testing
+
+- Write unit tests for new features
+- Update existing tests when modifying features
+- Include integration tests where appropriate
+- Test on all supported platforms if possible
+
+## Release Process
+
+1. Version bumps are handled automatically via GitHub Actions
+2. Releases are created from the main branch
+3. Changelog is generated automatically
+4. Builds are created for all platforms
+
+## Getting Help
+
+- Check existing documentation
+- Ask in GitHub Discussions
+- Contact maintainers:
+  - Umer Farooq (@umerfarok)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,37 @@
+---
+name: Bug report
+about: Create a report to help us improve NetworkMonitor
+title: '[BUG] '
+labels: bug
+assignees: ''
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Environment (please complete the following information):**
+ - OS: [e.g. Windows 10]
+ - Python Version: [e.g. 3.9.0]
+ - NetworkMonitor Version: [e.g. 0.1.0]
+ - Npcap Version: [e.g. 1.60]
+
+**Log Files**
+Please attach the following logs if available:
+- NetworkMonitor log (`%LOCALAPPDATA%\NetworkMonitor\logs\networkmonitor.log`)
+- Debug log (`networkmonitor_debug.log`)
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,19 @@
+---
+name: Feature request
+about: Suggest an idea for NetworkMonitor
+title: '[FEATURE] '
+labels: enhancement
+assignees: ''
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/SECURITY.md

@@ -0,0 +1,70 @@
+# Security Policy
+
+## Supported Versions
+
+We currently support the following versions of NetworkMonitor with security updates:
+
+| Version | Supported          |
+| ------- | ------------------ |
+| 0.1.x   | :white_check_mark: |
+
+## Reporting a Vulnerability
+
+We take security vulnerabilities seriously. Please follow these steps to report a security issue:
+
+1. **DO NOT** open a public GitHub issue if the bug is a security vulnerability.
+2. Instead, please send an email to umerfarooq.dev@gmail.com with:
+   - Subject line: "Security Vulnerability: NetworkMonitor"
+   - Description of the vulnerability
+   - Steps to reproduce (if possible)
+   - Potential impact
+   - Any suggested fixes (if you have them)
+
+### What to expect:
+- Acknowledgment within 48 hours
+- Regular updates on the progress
+- Credit in the security advisory when the issue is fixed
+
+## Security Best Practices
+
+When using NetworkMonitor:
+
+1. Always run with minimum required privileges
+2. Keep the software updated to the latest version
+3. Monitor logs for suspicious activity
+4. Follow network security best practices
+5. Report any security concerns immediately
+
+## Disclosure Timeline
+
+Our standard disclosure timeline:
+
+1. **0 hours**: Initial report received
+2. **48 hours**: Initial acknowledgment
+3. **7 days**: Initial assessment completed
+4. **30 days**: Fix developed and tested
+5. **45 days**: Fix released
+6. **60 days**: Public disclosure
+
+This timeline may be adjusted based on severity and complexity.
+
+## Security Updates
+
+Security updates are distributed through:
+- GitHub Releases
+- Security Advisories
+- Email notifications (for registered users)
+
+## Code Security
+
+We maintain security through:
+
+1. Regular dependency updates
+2. Automated security scanning
+3. Code review requirements
+4. Security-focused testing
+5. Regular security audits
+
+## Acknowledgments
+
+We appreciate the security research community's efforts in responsibly disclosing vulnerabilities. Security researchers who have contributed will be credited in our Hall of Fame (unless they wish to remain anonymous).

.github/pull_request_template.md

@@ -0,0 +1,28 @@
+## Description
+Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.
+
+Fixes # (issue)
+
+## Type of change
+Please delete options that are not relevant.
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+
+## How Has This Been Tested?
+Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
+
+- [ ] Test A
+- [ ] Test B
+
+## Checklist:
+- [ ] My code follows the style guidelines of this project
+- [ ] I have performed a self-review of my own code
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have made corresponding changes to the documentation
+- [ ] My changes generate no new warnings
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] New and existing unit tests pass locally with my changes
+- [ ] Any dependent changes have been merged and published in downstream modules