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 devCode Standards
- Use TypeScript with strict type checking
- Never use
anytype - 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 logicPull 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.tsxDocumentation 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:
Automated Checks
CI runs tests, linting, and type checking
Code Review
Maintainers review code quality, architecture, and adherence to guidelines
Design Review
For UI components, designers review visual implementation and UX
Accessibility Review
Verify keyboard navigation, screen reader support, and WCAG compliance
Feedback and Iteration
Address feedback and make requested changes
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:
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.