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.
6.5 KiB
Official Builds vs Self-Hosted
TimeTracker supports two deployment models with different analytics configurations.
Official Builds
Official builds are published on GitHub Container Registry with analytics pre-configured for community support.
Characteristics
- Analytics Keys: PostHog and Sentry keys are embedded at build time
- Telemetry: Opt-in during first-time setup (disabled by default)
- Privacy: No PII is ever collected, even with telemetry enabled
- Updates: Automatic community insights help improve the product
- Support: Anonymous usage data helps prioritize features
Using Official Builds
# Pull the official image
docker pull ghcr.io/YOUR_USERNAME/timetracker:latest
# Run with default configuration
docker-compose up -d
On first access, you'll see the setup page where you can:
- ✅ Enable telemetry to support community development
- ⬜ Disable telemetry for complete privacy (default)
What Gets Tracked (If Enabled)
- Event types (e.g., "timer.started", "project.created")
- Internal numeric IDs (no usernames or emails)
- Anonymous installation fingerprint
- Platform and version information
What's NEVER Tracked
- ❌ Email addresses or usernames
- ❌ Project names or descriptions
- ❌ Time entry notes or content
- ❌ Client information or business data
- ❌ IP addresses
- ❌ Any personally identifiable information
Self-Hosted Builds
Self-hosted builds give you complete control over analytics and telemetry.
Build Your Own Image
# Clone the repository
git clone https://github.com/YOUR_USERNAME/timetracker.git
cd timetracker
# Build without embedded keys
docker build -t timetracker:self-hosted .
# Run your build
docker run -p 5000:5000 timetracker:self-hosted
Configuration Options
Option 1: No Analytics (Default)
No configuration needed. Analytics placeholders remain empty.
# Just run it
docker-compose up -d
Option 2: Your Own Analytics
Provide your own PostHog/Sentry keys:
# .env file
POSTHOG_API_KEY=your-posthog-key
POSTHOG_HOST=https://your-posthog-instance.com
SENTRY_DSN=your-sentry-dsn
Option 3: Official Keys (If You Have Them)
If you have the official keys, you can use them:
export POSTHOG_API_KEY="official-key"
docker-compose up -d
Comparison
| Feature | Official Build | Self-Hosted |
|---|---|---|
| Analytics Keys | Embedded | User-provided or none |
| Telemetry Default | Opt-in (disabled) | Opt-in (disabled) |
| Privacy | No PII ever | No PII ever |
| Updates | Via GitHub Releases | Manual builds |
| Support Data | Optional community sharing | Private only |
| Customization | Standard | Full control |
Transparency & Trust
Official Build Process
- GitHub Actions Trigger: Tag pushed (e.g.,
v3.0.0) - Placeholder Replacement: Analytics keys injected from GitHub Secrets
- Docker Build: Image built with embedded keys
- Image Push: Published to GitHub Container Registry
- Release Creation: Changelog and notes generated
Verification
You can verify the build process:
# Check if this is an official build
docker run ghcr.io/YOUR_USERNAME/timetracker:latest python3 -c \
"from app.config.analytics_defaults import is_official_build; \
print('Official build' if is_official_build() else 'Self-hosted')"
Source Code Availability
All code is open source:
- Analytics configuration:
app/config/analytics_defaults.py - Build workflow:
.github/workflows/build-and-publish.yml - Telemetry code:
app/utils/telemetry.py
Override Priority
Configuration is loaded in this priority order (highest first):
- Environment Variables (user override)
- Built-in Defaults (from GitHub Actions for official builds)
- Empty/Disabled (for self-hosted without config)
This means you can always override official keys with your own:
# Even in an official build, you can use your own keys
export POSTHOG_API_KEY="my-key"
docker-compose up -d
Privacy Guarantees
For Official Builds
- ✅ Telemetry is opt-in (disabled by default)
- ✅ Can be disabled anytime in admin dashboard
- ✅ No PII is ever collected
- ✅ Open source code for full transparency
For Self-Hosted
- ✅ Complete control over all analytics
- ✅ Can disable entirely by not providing keys
- ✅ Can use your own PostHog/Sentry instances
- ✅ Same codebase, just without embedded keys
FAQ
Q: Will the official build send my data without permission? A: No. Telemetry is disabled by default. You must explicitly enable it during setup or in admin settings.
Q: Can I audit what data is sent?
A: Yes. All tracked events are documented in docs/all_tracked_events.md and logged locally in logs/app.jsonl.
Q: Can I use the official build without telemetry? A: Yes! Just leave telemetry disabled during setup. The embedded keys are only used if you opt in.
Q: What's the difference between official and self-hosted? A: Official builds have analytics keys embedded (but still opt-in). Self-hosted builds require you to provide your own keys or run without analytics.
Q: Can I switch from official to self-hosted?
A: Yes. Your data is stored locally in the database. Just migrate your data/ directory and database to a self-hosted instance.
Q: Are the analytics keys visible in the official build? A: They're embedded in the built image (not in source code). This is standard practice for analytics (like mobile apps).
Building Official Releases
Prerequisites
- GitHub repository with Actions enabled
- GitHub Secrets configured:
POSTHOG_API_KEY: Your PostHog project API keySENTRY_DSN: Your Sentry project DSN
Release Process
# Create and push a version tag
git tag v3.0.0
git push origin v3.0.0
# GitHub Actions will automatically:
# 1. Inject analytics keys
# 2. Build Docker image
# 3. Push to GHCR
# 4. Create GitHub Release
Manual Trigger
You can also trigger builds manually:
- Go to Actions tab in GitHub
- Select "Build and Publish Official Release"
- Click "Run workflow"
- Enter version (e.g.,
3.0.0) - Click "Run workflow"
Support
- Official Builds: GitHub Issues, Community Forum
- Self-Hosted: GitHub Issues, Documentation
- Privacy Concerns: See
docs/privacy.md - Security Issues: See
SECURITY.md
Remember: Whether you use official or self-hosted builds, TimeTracker respects your privacy. Telemetry is always opt-in, transparent, and never collects PII.