Contributing Guide

Learn how to contribute to the Odysee.ai frontend

Git Workflow

We use a Git Flow Workflow with multiple environments and automated CI/CD pipelines.

Branch Structure

Environments

EnvironmentBranchURLPurpose
PreviewFeature PRspreview-xyz.vercel.appFeature review & testing
Developdevelopdev.odysee.aiIntegration testing
Stagingrelease/*staging.odysee.aiPre-production testing
Productionmainapp.odysee.aiLive application

Branch Naming Convention

All feature branches must follow this naming pattern:

<type>/<jira-ticket>/<short-description>

Branch Types

  • feature/ or feat/ - New features
  • fix/ or bugfix/ - Bug fixes
  • hotfix/ - Critical production fixes
  • chore/ - Maintenance tasks
  • docs/ - Documentation updates
  • refactor/ - Code refactoring
  • test/ - Test additions or modifications

Examples

# Feature branch
sierra-1000/user-authentication

# Bug fix
sierra-1001/fix-login-redirect

# Hotfix
sierra-1002/critical-api-error

# Chore
sierra-1003/update-dependencies

The JIRA ticket number (e.g., SIERRA-1000) is required for all branches. This ensures traceability between code changes and project management.

Development Workflow

Start a New Feature

# Ensure you're on the latest develop branch
git checkout develop
git pull origin develop

# Create your feature branch
git checkout -b sierra-1000/user-authentication

# Start development
pnpm dev

Make Changes

Follow these guidelines while developing:

Code Quality

  • Write clean, readable code
  • Follow TypeScript best practices
  • Ensure no TypeScript errors (pnpm typecheck)
  • Add tests for new functionality
  • Update documentation if needed

Before Committing

# Lint your code
pnpm lint:fix

# Type check
pnpm typecheck

# Run tests
cd apps/web
pnpm test

Git hooks will automatically run these checks on commit. If they fail, your commit will be blocked.

Commit Your Changes

We follow Conventional Commits specification:

Commit Message Format

<type>[(optional scope)]: <description>

[optional body]

[optional footer(s)]

Commit Types

TypeDescriptionExample
featNew featurefeat(auth): add Google OAuth integration
fixBug fixfix(ui): resolve button alignment in mobile
docsDocumentationdocs: update API integration guide
styleCode style/formattingstyle: format code with Prettier
refactorCode refactoringrefactor(api): simplify error handling
perfPerformance improvementperf: optimize image loading
testAdding/updating teststest(auth): add login flow tests
choreMaintenance taskschore: update dependencies
ciCI/CD changesci: add deployment workflow

Commit Examples

# Feature with scope
git commit -m "feat(guest-disruptions): add alternative pathways tab"

# Bug fix
git commit -m "fix(auth): resolve token refresh issue"

# Documentation
git commit -m "docs: add architecture diagrams"

# Multiple changes
git commit -m "chore: update Material-UI to v7.2.0

- Update all MUI packages
- Update theme configuration
- Fix breaking changes in components"

# Breaking change
git commit -m "feat(api)!: change authentication endpoint

BREAKING CHANGE: Auth endpoint moved from /api/auth to /api/v2/auth"

Commit Message Rules

  • Use imperative mood ("add" not "added" or "adds")
  • Don't capitalize first letter
  • No period at the end of subject line
  • Keep subject line under 72 characters
  • Reference JIRA tickets in body if needed

Commits that don't follow the conventional format will be rejected by the commit-msg hook.

Push Your Changes

# Push your branch
git push origin sierra-1000/user-authentication

Create a Pull Request

PR to Develop

  1. Go to GitHub repository
  2. Click "New Pull Request"
  3. Set base branch to develop
  4. Set compare branch to your feature branch
  5. Fill out the PR template

PR Title Format

Use the same format as commit messages:

feat(auth): add Google OAuth integration

PR Description Template

## Description

Brief description of what this PR does.

## Related Ticket

SIERRA-1000

## Changes Made

- Added Google OAuth provider
- Updated authentication flow
- Added user profile sync

## Testing

- [ ] Tested login flow
- [ ] Tested signup flow
- [ ] Tested token refresh
- [ ] Tested on mobile devices

## Screenshots

[If applicable, add screenshots]

## Checklist

- [ ] Code follows project conventions
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No console errors
- [ ] TypeScript errors resolved
- [ ] Lint checks pass

Automated Checks

When you create a PR, the following automated checks run:

Preview deployments are automatically created for every PR. Check the bot comment for the preview URL.

Code Review

Review Process

  1. Self-review: Review your own PR first
  2. Team review: At least 1 approval required
  3. Address feedback: Make requested changes
  4. Re-review: Request re-review after changes

Reviewer Responsibilities

  • Check code quality and style
  • Verify functionality
  • Test preview deployment
  • Review test coverage
  • Check for security issues
  • Ensure documentation is updated

Addressing Review Comments

# Make requested changes
git add .
git commit -m "fix: address review feedback"
git push origin sierra-1000/user-authentication

# Request re-review on GitHub

Merge to Develop

Once approved:

  1. Ensure all checks pass
  2. Resolve any conflicts
  3. Squash and merge (preferred) or merge
  4. Delete branch after merge

The merge to develop automatically:

  • Deploys to dev.odysee.ai
  • Runs full test suite
  • Updates preview deployments

Release Process

Creating a Release

When develop is stable and ready for production:

Create Release Branch

# From develop
git checkout develop
git pull origin develop

# Create release branch (follow semantic versioning)
git checkout -b release/v1.2.0
git push origin release/v1.2.0

This automatically:

  • Deploys to staging.odysee.ai
  • Creates GitHub comment with staging URL
  • Runs all CI checks

Test on Staging

  • Perform comprehensive testing on staging
  • Fix any bugs directly on release branch
  • Each push updates staging automatically
# If bugs found, fix on release branch
git checkout release/v1.2.0
git commit -m "fix: critical issue on release"
git push origin release/v1.2.0

Merge to Main

When staging testing is complete:

  1. Create PR: release/v1.2.0main
  2. Get approval from tech lead
  3. Merge to main

This automatically:

  • Creates git tag v1.2.0
  • Generates changelog
  • Creates GitHub Release
  • Deploys to production (app.odysee.ai)
  • Merges release back to develop
  • Deletes release branch

Merging to main deploys to production. Ensure thorough testing on staging first.

Hotfixes

For critical production issues:

# From main
git checkout main
git pull origin main

# Create hotfix branch
git checkout -b sierra-2000/critical-fix

# Fix the issue
git commit -m "fix: critical production issue"
git push origin sierra-2000/critical-fix

# Create PR to main
# After merge, manually merge to develop

Code Style Guidelines

TypeScript

// Explicit types, clear naming
interface UserProfile {
  id: string;
  email: string;
  name: string;
  createdAt: Date;
}

const fetchUserProfile = async (userId: string): Promise<UserProfile> => {
  const response = await fetch(`/api/users/${userId}`);

  if (!response.ok) {
    throw new Error('Failed to fetch user profile');
  }

  return response.json();
};
// Implicit any, unclear naming
const getData = async (id) => {
  const res = await fetch(`/api/users/${id}`);
  return res.json();
};

React Components

// Typed props, clear structure
interface ButtonProps {
  label: string;
  onClick: () => void;
  variant?: 'primary' | 'secondary';
  disabled?: boolean;
}

export const Button = ({
  label,
  onClick,
  variant = 'primary',
  disabled = false
}: ButtonProps) => {
  return (
    <button
      onClick={onClick}
      disabled={disabled}
      className={`btn btn-${variant}`}
    >
      {label}
    </button>
  );
};
// No types, unclear props
export const Button = (props) => {
  return <button onClick={props.onClick}>{props.children}</button>;
};

Server Components vs Client Components

// Default in Next.js 15 - No "use client" directive
// Can fetch data directly
import { getGuestDisruptions } from '@/app/actions/guest-disruptions';

export default async function GuestDisruptionsPage() {
  const disruptions = await getGuestDisruptions();

  return <GuestDisruptionsTable data={disruptions} />;
}
// Use "use client" for interactivity
'use client';

import { useState } from 'react';

export const InteractiveTable = ({ data }) => {
  const [selected, setSelected] = useState<string[]>([]);
  // ... interactive logic
};

Error Handling

// Comprehensive error handling
try {
  const result = await fetchData();
  return { success: true, data: result };
} catch (error) {
  console.error('API call failed:', error);
  return {
    success: false,
    error: error instanceof Error ? error.message : 'Unknown error'
  };
}
// Swallowing errors
try {
  return await fetchData();
} catch (e) {
  console.log(e);
}

Documentation Standards

Code Comments

// Explains WHY, not WHAT
// Fetch disruptions in parallel to avoid waterfall requests
const [disruptions, pathways] = await Promise.all([
  getGuestDisruptions(),
  getAlternativePathways(),
]);
// States the obvious
// Call getGuestDisruptions function
const disruptions = await getGuestDisruptions();

Component Documentation

Add JSDoc comments for exported components:

/**
 * Primary button component for user actions
 *
 * @param label - Button text content
 * @param onClick - Click handler function
 * @param variant - Visual style variant
 * @param disabled - Whether button is disabled
 *
 * @example
 * ```tsx
 * <Button
 *   label="Submit"
 *   onClick={handleSubmit}
 *   variant="primary"
 * />
 * ```
 */
export const Button = ({ label, onClick, variant, disabled }: ButtonProps) => {
  // ...
}

Common Issues and Solutions

Best Practices Summary

  • Follow branch naming convention with JIRA tickets
  • Write conventional commit messages
  • Add tests for new features
  • Update documentation
  • Request reviews from appropriate team members
  • Test on preview deployment before merging
  • Keep PRs focused and reasonably sized
  • Respond to review feedback promptly
  • Don't commit directly to main or develop
  • Don't skip tests or type checks
  • Don't merge without approvals
  • Don't commit sensitive data (API keys, secrets)
  • Don't leave console.log statements
  • Don't merge failing CI checks
  • Don't create giant PRs (split into smaller ones)
  • Don't bypass git hooks unless absolutely necessary

Getting Help

If you're stuck or have questions:

  1. Check this documentation
  2. Review similar PRs for examples
  3. Ask in the team chat
  4. Reach out to tech leads
  5. Review component examples in Storybook

Ready to understand the codebase architecture? Continue to Architecture.