Contributing Guide

How to contribute to Fidus Design System and help improve it for everyone

Welcome Contributors

We welcome contributions to Fidus Design System from the community. Whether you are fixing bugs, adding new components, improving documentation, or suggesting enhancements, your contributions help make the design system better for everyone.

This guide will help you understand how to contribute effectively and what standards we expect.

Code of Conduct

By participating in this project, you agree to abide by our code of conduct:

Our Standards

  • Be respectful and inclusive in all interactions
  • Welcome diverse perspectives and experiences
  • Focus on what is best for the community
  • Show empathy towards other contributors
  • Accept constructive criticism gracefully
  • Prioritize user privacy and security

Unacceptable Behavior

  • Harassment, discrimination, or offensive comments
  • Personal attacks or trolling
  • Sharing private information without consent
  • Spam or off-topic content
  • Any conduct that would be inappropriate in a professional setting

How to Report Bugs

If you find a bug in a component or documentation, please report it through GitHub Issues.

Before Reporting

  • Check if the issue has already been reported
  • Verify you are using the latest version
  • Try to reproduce the issue consistently
  • Gather relevant information (browser, OS, version)

Bug Report Template

**Component:** Button

**Version:** 1.2.3

**Description:**
Clear description of the bug and what you expected to happen.

**Steps to Reproduce:**
1. Import Button component
2. Set variant to "primary"
3. Click the button
4. Observe incorrect behavior

**Expected Behavior:**
What should happen

**Actual Behavior:**
What actually happens

**Environment:**
- Browser: Chrome 120
- OS: macOS 14
- React: 18.2
- Node: 20.10

**Code Example:**
```tsx
<Button variant="primary" onClick={handleClick}>
  Click me
</Button>
```

**Screenshots:**
If applicable, add screenshots to help explain the problem.

**Additional Context:**
Any other relevant information.

Feature Requests

We welcome ideas for new components, patterns, or enhancements to existing features.

Before Requesting

  • Check if a similar feature has been requested
  • Consider if it fits the design system philosophy
  • Think about how it would benefit other users
  • Prepare examples or mockups if possible

Feature Request Template

**Feature Type:** New Component / Enhancement / Pattern

**Title:** Clear, descriptive title

**Problem Statement:**
What problem does this solve? Why is it needed?

**Proposed Solution:**
How would this feature work? Include details about:
- API design (props, events)
- Visual appearance
- Behavior and interactions
- Accessibility considerations

**Alternatives Considered:**
What other approaches did you consider?

**Use Cases:**
Specific examples of when this would be used

**Privacy Considerations:**
How does this relate to user privacy?

**Additional Context:**
Mockups, code examples, references to similar implementations

Pull Request Guidelines

Ready to contribute code? Follow these guidelines to ensure your pull request can be reviewed and merged smoothly.

Before You Start

  • Fork the repository and create a new branch
  • For significant changes, open an issue first to discuss
  • Read the architecture and design philosophy documentation
  • Set up your development environment

Development Setup

# Clone your fork
git clone https://github.com/YOUR_USERNAME/fidus.git
cd fidus

# Install dependencies
pnpm install

# Run tests
pnpm test

# Start development server
cd packages/design-system
pnpm dev

Code Standards

  • Use TypeScript with strict type checking
  • Never use any type
  • Avoid type casting with as
  • Follow existing code style and conventions
  • Use CSS variables for spacing and colors
  • Never hardcode spacing values
  • Include proper TypeScript types for all props
  • Write clear, descriptive variable and function names

Commit Messages

Use conventional commit format:

feat(button): add loading state
fix(input): correct validation error display
docs(contributing): update PR guidelines
test(card): add accessibility tests
refactor(modal): simplify animation logic

Pull Request Checklist

Before submitting, ensure:

  • All tests pass locally
  • Code follows style guidelines
  • TypeScript types are correct (no any)
  • Documentation is updated
  • Accessibility requirements met (WCAG 2.1 AA)
  • Tests added for new functionality
  • Privacy considerations addressed
  • Component works with keyboard navigation
  • Component is responsive

Component Contribution Checklist

Contributing a new component? Here is everything you need to include:

1. Component Implementation

  • TypeScript component with strict types
  • Props interface with JSDoc comments
  • Variants and sizes as needed
  • Disabled, loading, and error states
  • Keyboard navigation support
  • ARIA attributes for accessibility
  • Responsive behavior

2. Styling

  • Use Tailwind CSS classes
  • Use CSS variables for spacing and colors
  • Never hardcode pixel values
  • Support dark mode
  • Proper focus states

3. Tests

  • Unit tests with Vitest
  • Render tests for all variants
  • Interaction tests (click, keyboard)
  • Accessibility tests
  • Test coverage above 80%

4. Documentation

  • Component page in design system site
  • Description and use cases
  • Props table with types and defaults
  • Code examples for common scenarios
  • Accessibility guidelines
  • Do's and Don'ts

5. Export

  • Add to main index.ts exports
  • Update package exports
  • Add to component list in documentation

Testing Requirements

All contributions must include tests. We use Vitest for component testing.

Example Test

import { render, screen, fireEvent } from '@testing-library/react';
import { describe, it, expect, vi } from 'vitest';
import { Button } from './Button';

describe('Button', () => {
  it('should render with text', () => {
    render(<Button>Click me</Button>);
    expect(screen.getByText('Click me')).toBeInTheDocument();
  });

  it('should call onClick when clicked', () => {
    const handleClick = vi.fn();
    render(<Button onClick={handleClick}>Click me</Button>);

    fireEvent.click(screen.getByText('Click me'));
    expect(handleClick).toHaveBeenCalledOnce();
  });

  it('should be disabled when disabled prop is true', () => {
    render(<Button disabled>Click me</Button>);
    expect(screen.getByText('Click me')).toBeDisabled();
  });

  it('should have correct ARIA attributes', () => {
    render(<Button aria-label="Submit form">Submit</Button>);
    expect(screen.getByRole('button')).toHaveAttribute(
      'aria-label',
      'Submit form'
    );
  });

  it('should support keyboard navigation', () => {
    const handleClick = vi.fn();
    render(<Button onClick={handleClick}>Click me</Button>);

    const button = screen.getByText('Click me');
    fireEvent.keyDown(button, { key: 'Enter' });
    expect(handleClick).toHaveBeenCalledOnce();
  });
});

Running Tests

# Run all tests
pnpm test

# Run tests in watch mode
pnpm test:watch

# Run tests with coverage
pnpm test:coverage

# Run specific test file
pnpm test Button.test.tsx

Documentation Requirements

Good documentation is essential. All components must have comprehensive documentation.

Documentation Page Structure

  • Clear description of component purpose
  • When to use and when not to use
  • Interactive examples
  • Props table with types, defaults, descriptions
  • Variants and states
  • Accessibility information
  • Best practices
  • Related components

Review Process

After submitting a pull request, here is what happens:

1

Automated Checks

CI runs tests, linting, and type checking

2

Code Review

Maintainers review code quality, architecture, and adherence to guidelines

3

Design Review

For UI components, designers review visual implementation and UX

4

Accessibility Review

Verify keyboard navigation, screen reader support, and WCAG compliance

5

Feedback and Iteration

Address feedback and make requested changes

6

Merge

Once approved, your PR is merged and included in the next release

Community Support

Need help with your contribution? Here is where to get support:

GitHub Discussions

Ask questions, share ideas, and get feedback from the community

Join discussions →

Discord

Real-time chat with maintainers and contributors

Join Discord →

Thank You

Thank you for considering contributing to Fidus Design System. Your contributions help create better, more accessible, and more privacy-focused experiences for all users.

We look forward to reviewing your contributions and working with you to make the design system even better.