这是indexloc提供的服务,不要输入任何密码
Skip to content

jeevan1985/open-notebook

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

GitHub Workflow & Templates

This folder contains GitHub-specific configuration for Open Notebook's contribution workflow.

📋 Issue Templates

We have three issue templates to guide contributors:

🐛 Bug Report (ISSUE_TEMPLATE/bug_report.yml)

For reporting bugs or unexpected behavior when the app is running but misbehaving.

Key Features:

  • Structured format for bug details
  • Environment and version information
  • Checkbox for contributors who want to fix the issue
  • Automatic bug and needs-triage labels

When to Use: App is installed and running, but something doesn't work as expected.

✨ Feature Request (ISSUE_TEMPLATE/feature_request.yml)

For suggesting new features or improvements.

Key Features:

  • Description of the feature
  • Explanation of why it would be helpful
  • Space for proposed solution
  • Checkbox for contributors who want to implement it
  • Automatic enhancement and needs-triage labels

When to Use: You have an idea for a new feature or improvement.

🔧 Installation Issue (ISSUE_TEMPLATE/installation_issue.yml)

For problems with installation or setup.

Key Features:

  • Deployment type selection
  • Environment details
  • Error message collection
  • Automatic installation label

When to Use: Having trouble getting Open Notebook running.

🔄 Pull Request Template

The PR template (pull_request_template.md) ensures contributors provide all necessary information:

Sections:

  • Description and related issue
  • Type of change
  • Testing details
  • Design alignment with project principles
  • Comprehensive checklist for code quality, testing, documentation
  • Screenshots for UI changes

Key Checkpoints:

  • References an approved issue
  • Aligns with design principles
  • Includes tests and documentation
  • Follows code style guidelines

🚀 GitHub Actions

Our CI/CD workflows in .github/workflows/:

build-and-release.yml

  • Builds Docker images on releases
  • Publishes to Docker Hub and GitHub Container Registry
  • Supports multi-platform builds (amd64, arm64)

build-dev.yml

  • Builds dev images on pushes to main
  • Tags with commit SHA for testing

claude-code-review.yml

  • Automated code review using Claude Code
  • Runs on pull requests
  • Provides AI-powered suggestions

📖 How the Contribution Flow Works

┌─────────────────────────────────────────────────────────┐
│ 1. Contributor identifies a bug or has a feature idea   │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 2. Creates an issue using appropriate template          │
│    - Describes the problem/feature                      │
│    - Checks "I am a developer..." if willing to work    │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 3. Maintainer reviews issue (within 48 hours)           │
│    - Assesses alignment with design principles          │
│    - Labels appropriately                               │
│    - Asks for clarification if needed                   │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 4. If approved: Contributor proposes solution approach  │
│    - Discusses implementation strategy                  │
│    - Maintainer provides feedback                       │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 5. Issue is assigned to contributor                     │
│    - Contributor forks repo                             │
│    - Creates feature branch from main                   │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 6. Contributor develops solution                        │
│    - Reads DESIGN_PRINCIPLES.md                         │
│    - Reads docs/development/architecture.md             │
│    - Writes code, tests, documentation                  │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 7. Creates Pull Request                                 │
│    - Uses PR template                                   │
│    - References issue number                            │
│    - Fills out all checklist items                      │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 8. Maintainer reviews PR                                │
│    - Checks code quality                                │
│    - Verifies tests pass                                │
│    - Ensures alignment with architecture                │
│    - Provides feedback or approves                      │
└────────────────────┬────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────┐
│ 9. If approved: PR is merged! 🎉                        │
│    - Contributor is thanked                             │
│    - Issue is closed                                    │
│    - Changes included in next release                   │
└─────────────────────────────────────────────────────────┘

🎯 Why This Process?

Prevents Wasted Effort

  • Contributors don't spend time on code that won't be merged
  • Ensures alignment with project vision before coding starts

Maintains Quality

  • All code reviewed against design principles
  • Consistent architecture across contributions
  • Proper testing and documentation

Respects Everyone's Time

  • Clear expectations upfront
  • Structured feedback process
  • Efficient review process

Protects Project Vision

  • Maintainers can guide direction
  • Features align with long-term goals
  • Technical debt is minimized

📚 Related Documentation

For contributors:

For maintainers:

🤝 Questions?


Thank you for contributing to Open Notebook! Your contributions help make this the best open-source research tool available.

About

An Open Source implementation of Notebook LM with more flexibility and features

Resources

License

Contributing

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • TypeScript 56.0%
  • Python 41.2%
  • Jinja 1.5%
  • Makefile 0.6%
  • CSS 0.5%
  • Dockerfile 0.2%