CONTRIBUTING

BUILD TOOLS FOR THE PEOPLE

We build tools, you build the future. Whether you're fixing bugs, adding components, or improving documentation, your work helps make powerful design tools accessible to anyone who needs to be heard.

CODE OF CONDUCT

Our values and principles

NO BULLSHIT

We support each other and work together without pretense
Direct communication, honest feedback, mutual respect

ACCESSIBILITY

Design tools should be available to everyone who needs them
WCAG compliance, screen reader support, keyboard navigation

TOOL BUILDING

We build tools, not messages - your voice is yours
Neutral platform for powerful communication

QUALITY

We maintain brutal standards and uncompromising accessibility
Code quality, design integrity, user experience

DEVELOPMENT SETUP

Get started with local development
BASH
# Fork and clone the repository
git clone https://github.com/b7r-dev/fyt.git
cd fyt

# Install dependencies
npm install

# Build Go CLI
cd cli && go build -o ../fyt .
cd ..

# Start development server
./fyt dev
# or
npm run dev

# Run validation
./fyt validate

# Build for production
./fyt build
# or
npm run build
Requirements:
  • Node.js 22+
  • Go 1.21+
  • npm or yarn

DESIGN PRINCIPLES

Core guidelines for contributions

COLOR SEPARATION

All colored elements must have 2px white separation for print clarity
Mandatory for brutal aesthetic and print optimization

REVOLUTIONARY TYPOGRAPHY

Use fonts that honor movement traditions: Bebas Neue, Anton, Courier Prime, Zilla Slab
Historical authenticity in type choices

PRINTING PRESS SIMULATION

Include halftone patterns and registration marks where appropriate
Authentic printing press aesthetic

ACCESSIBILITY FIRST

Ensure WCAG AA compliance minimum, AAA preferred
Screen readers, keyboard navigation, high contrast

HISTORICAL AUTHENTICITY

Research the graphic design heritage you're referencing
Honor movement traditions and design history

COMPONENT DEVELOPMENT

Step-by-step guide

RESEARCH HISTORICAL CONTEXT

Understand the movement or design tradition you're referencing

FOLLOW NAMING CONVENTIONS

Use descriptive names (e.g., BrutalAlert, HumanistQuote)

IMPLEMENT COLOR SEPARATION

Use printing press utilities for proper color separation

ADD TYPESCRIPT TYPES

Ensure full type safety with proper interfaces

INCLUDE DOCUMENTATION

Add YAML documentation in content/components/

TEST RESPONSIVENESS

Ensure components work across all devices and screen sizes

VERIFY ACCESSIBILITY

Test with screen readers and keyboard navigation

CODE STYLE

Standards and conventions

TYPESCRIPT

Use TypeScript for all new code with proper type definitions
No any types - use proper interfaces

NAMING CONVENTIONS

PascalCase for components, camelCase for functions
Follow existing patterns in codebase

TAILWIND CSS

Use Tailwind classes with our custom design tokens
Maintain brutal aesthetic with utility classes

COMMENTS & DOCS

Include JSDoc comments for complex functions
Document intent and edge cases

FORMATTING

Maintain consistent indentation (2 spaces)
Organize imports: React, third-party, local

LINTING & TYPE CHECKING

Run npm run lint and npx tsc --noEmit before committing
Fix all errors and warnings

PULL REQUEST PROCESS

How to submit changes
  1. Create Feature Branch: git checkout -b feature/your-feature-name
  2. Make Changes: Follow coding standards and design principles
  3. Test Your Work: Ensure everything works in development mode
  4. Update Documentation: Add or update relevant documentation in content/
  5. Commit with Clear Messages: Use descriptive commit messages
  6. Submit Pull Request: Include clear description of changes
Pull Request Template:
MARKDOWN
**Description:**
Brief description of what this PR does

**Type of Change:**
- [ ] Bug fix
- [ ] New component
- [ ] Documentation update
- [ ] Design token update
- [ ] Breaking change

**Testing:**
- [ ] Tested in development mode
- [ ] Tested responsive design
- [ ] Tested accessibility
- [ ] Validated YAML content

**Documentation:**
- [ ] Updated relevant documentation
- [ ] Added component documentation (if applicable)
- [ ] Updated changelog

DOCUMENTATION

Single source of truth
The application's documentation site (content/ directory) is the single source of truth for all technical documentation.
Documentation updates should be made in the content/ directory, NOT in repository markdown files. Repository markdown files (README.md, LICENSE, CONTRIBUTING.md) are for project overview and contribution guidelines only.
Documentation Structure:
  • content/pages/docs/guides/ - Implementation guides
  • content/pages/docs/technical/ - Technical documentation
  • content/pages/docs/audits/ - Audits and reports
  • content/components/ - Component documentation
  • content/design-tokens/ - Design system tokens
  • content/blog/ - Blog posts and articles
Adding Documentation:
  1. Create YAML files in the appropriate content/ directory
  2. Follow the structure of existing documentation files
  3. Ensure dual linking: link from at least two other pages
  4. Update navigation if adding new sections
  5. Test links in the application
  6. Run validation: ./fyt validate
Documentation Format:
  • Use YAML format for content files
  • Include clear sections: Overview, Features, Implementation, Testing
  • Add related documentation links
  • Include code examples where relevant
  • Use proper metadata (title, description, keywords, slug)
See also: Project TODO for documentation migration tasks

BUG REPORTS

How to report issues effectively

USE CLEAR TITLE

Describe the issue concisely in the title

EXPECTED VS ACTUAL

Describe what should happen vs what does happen

STEPS TO REPRODUCE

Provide detailed steps to reproduce the issue

SCREENSHOTS & ENVIRONMENT

Add screenshots if relevant. Specify browser, device, and OS

CONSOLE ERRORS

Include any console errors or warnings

FEATURE REQUESTS

Proposing new features

DESCRIBE USE CASE

Explain the user need and problem being solved
Focus on real-world communication needs

DESIGN PHILOSOPHY

Explain how it fits our brutal/humanist aesthetic
Maintain bold design principles

HISTORICAL CONTEXT

Include historical or movement context if relevant
Honor graphic design heritage

ACCESSIBILITY

Consider accessibility implications
WCAG compliance and inclusive design

IMPLEMENTATION

Suggest implementation approach if you have ideas
Technical details and considerations

WE ESPECIALLY WELCOME

Priority contribution areas
HIGH PRIORITY

HISTORICALLY-INFORMED COMPONENTS

Components that honor movement traditions and graphic design heritage
ALWAYS WELCOME

ACCESSIBILITY IMPROVEMENTS

Enhancements to screen reader support, keyboard navigation, and WCAG compliance
NEEDED

DOCUMENTATION ENHANCEMENTS

Improved guides, examples, and technical documentation
ONGOING

PERFORMANCE OPTIMIZATIONS

Bundle size reduction, build time improvements, runtime performance
CORE MISSION

PRINT OPTIMIZATION FEATURES

Enhanced print styles, ink conservation, paper size optimization

RECOGNITION & NEXT STEPS

Celebrating contributors and getting started

CONTRIBUTOR RECOGNITION

Significant improvements recognized in documentation and release notes
We celebrate those who advance our mission

CHECK PROJECT TODO

View current priorities and open tasks
Link: /docs/todo

REVIEW DOCUMENTATION

Understand the design system and implementation details
Link: /docs

BROWSE COMPONENTS

Explore the component library and design patterns
Link: /components

ASK QUESTIONS

Use GitHub issues for questions and discussions
Community support available

READ CONTRIBUTING.MD

Reference full contribution guidelines on GitHub
Additional details and policies
← BACK TO DOCUMENTATION INDEX