hanzoai/minutes
2
0
Fork 0
mirror of https://github.com/hanzoai/minutes.git synced 2026-10-30 18:27:58 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
minutes/CONTRIBUTING.md
T
zeekayandHanzo Dev ecd717c6fb the product is Minutes, and the archived tier is gone 
A fork of meetily (MIT, Zackriya Solutions) rebranded to Hanzo.

The Python/FastAPI tier, its Docker files, its whisper-server scripts and the
whisper.cpp submodule are deleted rather than rebranded. Upstream's own CLAUDE.md
says that tier is archived and unsupported and tells you not to add endpoints to
it; the shipping product is one Tauri binary that transcribes in-process with
whisper-rs and Parakeet. Rebranding a corpse would have doubled the surface and
taught the next reader that a dead service is a live one. Going with it: the
vestigial localhost:5167 gate the sidebar checked before reading its own
database.

.github/workflows goes too. This repo lives on git.hanzo.ai, which reads
.hanzo/workflows, and we do not use GitHub-hosted runners — six workflow files
that cannot run read like CI that passes. Nothing replaces them yet, because a
pipeline that has never run is worse than an honest absence.

Summaries are written by api.hanzo.ai, our own stack, and it is the default.
The other providers still compile and should go in a follow-up.

The upstream MIT notice stays and the Hanzo copyright joins it. About and the
README say plainly what this is a fork of.

Left alone deliberately, and each is a decision someone must still make: the
minisign updater key is upstream's and we cannot re-sign, so the updater points
at a release path that does not exist yet; the ffmpeg binaries still come from
upstream's GitHub; the Parakeet models still come from upstream's host.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-14 07:40:31 -07:00

3.4 KiB
Raw Permalink Blame History

Contributing to Meeting Minutes Updates

Thank you for your interest in contributing to Minutes! This document provides guidelines and instructions for contributing to this project.

Development Workflow

Branch Strategy

  • main - Production branch
  • devtest - Development and testing branch
  • Feature branches should be created from devtest

Getting Started

  1. Fork the repository
  2. Clone your fork: 
    git clone https://github.com/YOUR_USERNAME/meeting-minutes.git
  3. Add the original repository as upstream: 
    git remote add upstream https://git.hanzo.ai/hanzoai/minutes.git
  4. Create a new branch from devtest: 
    git checkout devtest
git pull upstream devtest
git checkout -b feature/your-feature-name

Development Process

  1. Always start your work from the devtest branch
  2. Create a new branch for each feature/fix
  3. Make your changes
  4. Write or update tests as needed
  5. Ensure all tests pass
  6. Update documentation if necessary

Issue Creation

Before starting work on a new feature or bug fix:

  1. Check if an issue already exists
  2. If not, create a new issue with:
    • Clear title
    • Detailed description
    • Steps to reproduce (for bugs)
    • Expected behavior
    • Screenshots (if applicable)
    • Labels (bug, enhancement, etc.)

Pull Request Process

  1. Create a PR from your feature branch to devtest
  2. Link the PR to the related issue using the issue number (e.g., "Fixes #123")
  3. Fill out the PR template completely
  4. Ensure CI checks pass
  5. Request review from at least one maintainer
  6. Address any review comments
  7. Once approved, the PR will be merged into devtest

PR Template

## Description
[Describe your changes here]

## Related Issue
[Link to the issue this PR addresses]

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Documentation update
- [ ] Performance improvement
- [ ] Code refactoring
- [ ] Other (please describe)

## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing performed
- [ ] All tests pass

## Documentation
- [ ] Documentation updated
- [ ] No documentation needed

## Checklist
- [ ] Code follows project style
- [ ] Self-reviewed the code
- [ ] Added comments for complex code
- [ ] Updated README if needed

Code Style

  • Follow the existing code style
  • Use meaningful variable and function names
  • Add comments for complex logic
  • Keep functions small and focused
  • Write clear commit messages

Commit Message Format

<type>(<scope>): <subject>

<body>

<footer>

Types:

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • style: Code style changes
  • refactor: Code refactoring
  • test: Adding/updating tests
  • chore: Maintenance tasks

Testing

  • Write unit tests for new features
  • Update existing tests when modifying code
  • Ensure all tests pass before submitting PR
  • Include integration tests for complex features

Documentation

  • Update documentation for new features
  • Keep README up to date
  • Document API changes
  • Add comments for complex code

Review Process

  1. PRs require at least one review
  2. Address all review comments
  3. Keep the PR up to date with devtest
  4. Squash commits if requested

Getting Help

  • Create an issue for questions
  • Join our community chat
  • Contact maintainers

License

By contributing, you agree that your contributions will be licensed under the project's MIT License.

Reference in New Issue View Git Blame Copy Permalink