Contributing to Aruuri

We warmly welcome contributions from individuals who are passionate about transforming giving through trust and transparency. Whether you're a developer, designer, or community member, your contributions help build the digital infrastructure for transparent, high-impact community funding.

This guide outlines the various ways you can contribute to the Aruuri project, along with our development standards and workflow. For a comprehensive overview of the platform's architecture and vision, please refer to the [Aruuri Platform Overview] page. If you're looking to set up your local development environment, start with [Getting Started with Aruuri Development].

How to Contribute

There are several ways to get involved and contribute to Aruuri:

1. Code Contributions: Help us build the core platform, implement new features, and squash bugs. This is primarily for developers working with TypeScript, Next.js, React, and our backend systems.
2. Design System: Contribute to our accessible and inclusive design system, ensuring a consistent and user-friendly experience across the platform. This involves working with Figma, Style Dictionary, Radix UI, and shadcn/ui.
3. Documentation: Enhance our project documentation, guides, and tutorials. Clear and comprehensive documentation is crucial for onboarding new contributors and users.
4. Community: Share your feedback, propose new ideas, help spread the word about Aruuri's mission, and engage in discussions to shape the future of transparent giving.

For detailed guidelines on contributing, please refer to our official CONTRIBUTING.md document in the repository.

Branch Naming Conventions

To maintain a clean and organized Git history, we follow specific branch naming conventions:

• feat/: For new features or enhancements.
  • Example: feat/add-dark-mode, feat/project-creation-flow
• fix/: For bug fixes.
  • Example: fix/donation-button-alignment, fix/login-error-message
• docs/: For documentation updates or additions.
  • Example: docs/update-readme, docs/add-api-reference
• chore/: For routine maintenance tasks, build process changes, or dependency updates that don't directly modify production code.
  • Example: chore/upgrade-nextjs, chore/update-eslint-config

Commit Convention

We adhere to the Conventional Commits↗ specification for our commit messages. This standard provides a clear and structured way to communicate the intent of each commit, making it easier for reviewers and for generating changelogs.

A conventional commit message should follow this structure:

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Key Elements:

• type: Required. Must be one of feat, fix, docs, chore, style, refactor, test, perf, ci, build, revert.
• scope: Optional. Indicates the part of the codebase affected (e.g., web, database, ui, utils, infrastructure).
• description: Required. A concise summary of the change.

Examples:

• feat(ui): add Dialog component
• fix(web): resolve donation flow error
• docs(readme): update installation steps
• chore(deps): update all dependencies
• refactor(database): improve connection pooling logic

For more in-depth information on our commit message standards, please consult docs/COMMIT_CONVENTIONS.md.

Pull Request (PR) Process

To contribute your changes to the main branch, please follow our Pull Request process:

1. Create a Feature Branch: Start by creating a new branch from main using one of the branch naming conventions.

2. Make Your Changes: Implement your feature, bug fix, or documentation update.
3. Add Tests: Ensure your changes are covered by appropriate unit, integration, or E2E tests. This is critical for maintaining code quality and preventing regressions. Refer to the [Development Workflow & Available Scripts] page for more on running tests.
4. Build and Verify: Before pushing your changes, run a full build to ensure everything compiles correctly and there are no unexpected issues.

5. Commit Your Changes: Stage and commit your changes using the Conventional Commits standard.

6. Push to GitHub: Push your local branch to the remote repository.

7. Submit a Pull Request (PR):
   • Go to the Aruuri GitHub repository and open a new Pull Request from your feature branch to the main branch.
   • Provide a clear and descriptive title that follows the Conventional Commits style (e.g., feat(web): Implement user profile page).
   • Write a detailed description of your changes, including:
     • What problem does this PR solve?
     • How was it solved?
     • Any relevant context, design decisions, or trade-offs.
     • Links to any related issues or discussions.
   • Request reviews from appropriate team members.
8. Wait for CI Checks and Review: Our Continuous Integration (CI) system will automatically run tests and linting checks on your PR. Address any failures or feedback from reviewers. Your PR will be merged once all checks pass and it has been approved by the required reviewers.

Thank you for your interest in contributing to Aruuri! Your efforts help us build a more transparent and impactful future for giving.