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
| Environment | Branch | URL | Purpose |
|---|---|---|---|
| Preview | Feature PRs | preview-xyz.vercel.app | Feature review & testing |
| Develop | develop | dev.odysee.ai | Integration testing |
| Staging | release/* | staging.odysee.ai | Pre-production testing |
| Production | main | app.odysee.ai | Live application |
Branch Naming Convention
All feature branches must follow this naming pattern:
<type>/<jira-ticket>/<short-description>Branch Types
feature/orfeat/- New featuresfix/orbugfix/- Bug fixeshotfix/- Critical production fixeschore/- Maintenance tasksdocs/- Documentation updatesrefactor/- Code refactoringtest/- 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-dependenciesThe 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 devMake 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 testGit 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
| Type | Description | Example |
|---|---|---|
feat | New feature | feat(auth): add Google OAuth integration |
fix | Bug fix | fix(ui): resolve button alignment in mobile |
docs | Documentation | docs: update API integration guide |
style | Code style/formatting | style: format code with Prettier |
refactor | Code refactoring | refactor(api): simplify error handling |
perf | Performance improvement | perf: optimize image loading |
test | Adding/updating tests | test(auth): add login flow tests |
chore | Maintenance tasks | chore: update dependencies |
ci | CI/CD changes | ci: 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-authenticationCreate a Pull Request
PR to Develop
- Go to GitHub repository
- Click "New Pull Request"
- Set base branch to
develop - Set compare branch to your feature branch
- Fill out the PR template
PR Title Format
Use the same format as commit messages:
feat(auth): add Google OAuth integrationPR 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 passAutomated 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
- Self-review: Review your own PR first
- Team review: At least 1 approval required
- Address feedback: Make requested changes
- 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 GitHubMerge to Develop
Once approved:
- Ensure all checks pass
- Resolve any conflicts
- Squash and merge (preferred) or merge
- 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.0This 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.0Merge to Main
When staging testing is complete:
- Create PR:
release/v1.2.0→main - Get approval from tech lead
- 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 developCode 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
mainordevelop - 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:
- Check this documentation
- Review similar PRs for examples
- Ask in the team chat
- Reach out to tech leads
- Review component examples in Storybook
Ready to understand the codebase architecture? Continue to Architecture.