mirror of
https://github.com/DRYTRIX/TimeTracker.git
synced 2025-12-21 02:40:08 -06:00
Complete reorganization of project documentation to improve discoverability, navigation, and maintainability. All documentation has been restructured into a clear, role-based hierarchy. ## Major Changes ### New Directory Structure - Created `docs/api/` for API documentation - Created `docs/admin/` with subdirectories: - `admin/configuration/` - Configuration guides - `admin/deployment/` - Deployment guides - `admin/security/` - Security documentation - `admin/monitoring/` - Monitoring and analytics - Created `docs/development/` for developer documentation - Created `docs/guides/` for user-facing guides - Created `docs/reports/` for analysis reports and summaries - Created `docs/changelog/` for detailed changelog entries (ready for future use) ### File Organization #### Moved from Root Directory (40+ files) - Implementation notes → `docs/implementation-notes/` - Test reports → `docs/testing/` - Analysis reports → `docs/reports/` - User guides → `docs/guides/` #### Reorganized within docs/ - API documentation → `docs/api/` - Administrator documentation → `docs/admin/` (with subdirectories) - Developer documentation → `docs/development/` - Security documentation → `docs/admin/security/` - Telemetry documentation → `docs/admin/monitoring/` ### Documentation Updates #### docs/README.md - Complete rewrite with improved navigation - Added visual documentation map - Organized by role (Users, Administrators, Developers) - Better categorization and quick links - Updated all internal links to new structure #### README.md (root) - Updated all documentation links to reflect new structure - Fixed 8 broken links #### app/templates/main/help.html - Enhanced "Where can I get additional help?" section - Added links to new documentation structure - Added documentation index link - Added admin documentation link for administrators - Improved footer with organized documentation links - Added "Complete Documentation" section with role-based links ### New Index Files - Created README.md files for all new directories: - `docs/api/README.md` - `docs/guides/README.md` - `docs/reports/README.md` - `docs/development/README.md` - `docs/admin/README.md` ### Cleanup - Removed empty `docs/security/` directory (moved to `admin/security/`) - Removed empty `docs/telemetry/` directory (moved to `admin/monitoring/`) - Root directory now only contains: README.md, CHANGELOG.md, LICENSE ## Results **Before:** - 45+ markdown files cluttering root directory - Documentation scattered across root and docs/ - Difficult to find relevant documentation - No clear organization structure **After:** - 3 files in root directory (README, CHANGELOG, LICENSE) - Clear directory structure organized by purpose and audience - Easy navigation with role-based organization - All documentation properly categorized - Improved discoverability ## Benefits 1. Better Organization - Documentation grouped by purpose and audience 2. Easier Navigation - Role-based sections (Users, Admins, Developers) 3. Improved Discoverability - Clear structure with README files in each directory 4. Cleaner Root - Only essential files at project root 5. Maintainability - Easier to add and organize new documentation ## Files Changed - 40+ files moved from root to appropriate docs/ subdirectories - 15+ files reorganized within docs/ - 3 major documentation files updated (docs/README.md, README.md, help.html) - 5 new README index files created - 2 empty directories removed All internal links have been updated to reflect the new structure.
248 lines
6.1 KiB
Markdown
248 lines
6.1 KiB
Markdown
# Contributing to TimeTracker
|
|
|
|
Thank you for your interest in contributing to TimeTracker! This document provides guidelines and information for contributors.
|
|
|
|
## Table of Contents
|
|
|
|
- [Code of Conduct](#code-of-conduct)
|
|
- [How Can I Contribute?](#how-can-i-contribute)
|
|
- [Development Setup](#development-setup)
|
|
- [Pull Request Process](#pull-request-process)
|
|
- [Coding Standards](#coding-standards)
|
|
- [Testing](#testing)
|
|
- [Reporting Bugs](#reporting-bugs)
|
|
- [Feature Requests](#feature-requests)
|
|
- [Questions and Discussion](#questions-and-discussion)
|
|
|
|
## Code of Conduct
|
|
|
|
This project and everyone participating in it is governed by our [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.
|
|
|
|
## How Can I Contribute?
|
|
|
|
### Reporting Bugs
|
|
|
|
- Use the GitHub issue tracker
|
|
- Include a clear and descriptive title
|
|
- Describe the exact steps to reproduce the bug
|
|
- Provide specific examples to demonstrate the steps
|
|
- Describe the behavior you observed after following the steps
|
|
- Explain which behavior you expected to see instead and why
|
|
- Include details about your configuration and environment
|
|
|
|
### Suggesting Enhancements
|
|
|
|
- Use the GitHub issue tracker
|
|
- Provide a clear and descriptive title
|
|
- Describe the suggested enhancement in detail
|
|
- Explain why this enhancement would be useful
|
|
- List any similar features and applications
|
|
|
|
### Pull Requests
|
|
|
|
- Fork the repository
|
|
- Create a feature branch (`git checkout -b feature/amazing-feature`)
|
|
- Make your changes
|
|
- Add tests for new functionality
|
|
- Ensure all tests pass
|
|
- Commit your changes (`git commit -m 'Add amazing feature'`)
|
|
- Push to the branch (`git push origin feature/amazing-feature`)
|
|
- Open a Pull Request
|
|
|
|
## Development Setup
|
|
|
|
### Prerequisites
|
|
|
|
- Python 3.11 or higher
|
|
- Docker and Docker Compose (for containerized development)
|
|
- Git
|
|
|
|
### Local Development
|
|
|
|
1. Clone the repository:
|
|
```bash
|
|
git clone https://github.com/drytrix/TimeTracker.git
|
|
cd TimeTracker
|
|
```
|
|
|
|
2. Create a virtual environment:
|
|
```bash
|
|
python -m venv venv
|
|
source venv/bin/activate # On Windows: venv\Scripts\activate
|
|
```
|
|
|
|
3. Install dependencies:
|
|
```bash
|
|
pip install -r requirements.txt
|
|
```
|
|
|
|
4. Set up environment variables:
|
|
```bash
|
|
cp .env.example .env
|
|
# Edit .env with your development settings
|
|
```
|
|
|
|
5. Initialize the database:
|
|
```bash
|
|
flask db upgrade
|
|
```
|
|
|
|
6. Run the development server:
|
|
```bash
|
|
flask run
|
|
```
|
|
|
|
### Docker Development
|
|
|
|
1. Build and start the containers:
|
|
```bash
|
|
docker-compose up --build
|
|
```
|
|
|
|
2. Access the application at `http://localhost:8080`
|
|
|
|
## Pull Request Process
|
|
|
|
1. **Fork and Clone**: Fork the repository and clone your fork locally
|
|
2. **Create Branch**: Create a feature branch from `main`
|
|
3. **Make Changes**: Implement your changes following the coding standards
|
|
4. **Test**: Ensure all tests pass and add new tests for new functionality
|
|
5. **Commit**: Write clear, descriptive commit messages
|
|
6. **Push**: Push your branch to your fork
|
|
7. **Submit PR**: Create a pull request with a clear description
|
|
|
|
### Commit Message Format
|
|
|
|
Use conventional commit format:
|
|
|
|
```
|
|
type(scope): description
|
|
|
|
[optional body]
|
|
|
|
[optional footer]
|
|
```
|
|
|
|
Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`
|
|
|
|
Examples:
|
|
- `feat(timer): add automatic idle detection`
|
|
- `fix(auth): resolve session timeout issue`
|
|
- `docs(readme): update installation instructions`
|
|
|
|
## Coding Standards
|
|
|
|
### Python
|
|
|
|
- Follow PEP 8 style guidelines
|
|
- Use type hints where appropriate
|
|
- Keep functions focused and single-purpose
|
|
- Write docstrings for all public functions and classes
|
|
- Maximum line length: 88 characters (use Black formatter)
|
|
|
|
### Flask
|
|
|
|
- Use blueprints for route organization
|
|
- Keep route handlers thin, move business logic to models or services
|
|
- Use proper HTTP status codes
|
|
- Implement proper error handling
|
|
|
|
### Database
|
|
|
|
- Use SQLAlchemy ORM for database operations
|
|
- Write migrations for schema changes
|
|
- Use proper indexing for performance
|
|
- Follow naming conventions for tables and columns
|
|
|
|
### Frontend
|
|
|
|
- Use semantic HTML
|
|
- Follow accessibility guidelines
|
|
- Keep CSS organized and maintainable
|
|
- Use HTMX for dynamic interactions
|
|
|
|
## Testing
|
|
|
|
### Running Tests
|
|
|
|
```bash
|
|
# Run all tests
|
|
python -m pytest
|
|
|
|
# Run with coverage
|
|
python -m pytest --cov=app
|
|
|
|
# Run specific test file
|
|
python -m pytest tests/test_timer.py
|
|
```
|
|
|
|
### Writing Tests
|
|
|
|
- Write tests for all new functionality
|
|
- Use descriptive test names
|
|
- Test both success and failure cases
|
|
- Mock external dependencies
|
|
- Use fixtures for common test data
|
|
|
|
### Test Structure
|
|
|
|
```
|
|
tests/
|
|
├── conftest.py # Shared fixtures
|
|
├── test_models/ # Model tests
|
|
├── test_routes/ # Route tests
|
|
├── test_utils/ # Utility function tests
|
|
└── integration/ # Integration tests
|
|
```
|
|
|
|
## Reporting Bugs
|
|
|
|
When reporting bugs, please include:
|
|
|
|
- **Environment**: OS, Python version, browser (if applicable)
|
|
- **Steps to Reproduce**: Clear, numbered steps
|
|
- **Expected Behavior**: What you expected to happen
|
|
- **Actual Behavior**: What actually happened
|
|
- **Screenshots**: If applicable
|
|
- **Logs**: Any error messages or logs
|
|
|
|
## Feature Requests
|
|
|
|
For feature requests:
|
|
|
|
- Explain the problem you're trying to solve
|
|
- Describe the proposed solution
|
|
- Provide use cases and examples
|
|
- Consider implementation complexity
|
|
- Discuss alternatives you've considered
|
|
|
|
## Questions and Discussion
|
|
|
|
- Use GitHub Discussions for general questions
|
|
- Use GitHub Issues for bugs and feature requests
|
|
- Be respectful and constructive
|
|
- Search existing issues before creating new ones
|
|
|
|
## Getting Help
|
|
|
|
If you need help:
|
|
|
|
1. Check the [README.md](README.md) for basic information
|
|
2. Search existing issues and discussions
|
|
3. Create a new issue or discussion
|
|
4. Join our community channels (if available)
|
|
|
|
## License
|
|
|
|
By contributing to TimeTracker, you agree that your contributions will be licensed under the same license as the project (GNU General Public License v3.0).
|
|
|
|
## Recognition
|
|
|
|
Contributors will be recognized in:
|
|
|
|
- The project's README.md
|
|
- Release notes
|
|
- Contributor statistics on GitHub
|
|
|
|
Thank you for contributing to TimeTracker! 🚀
|