Skip to content

Contributing

Jump to bottom
Parnian Hajian edited this page Apr 23, 2026 · 1 revision

Contributing

Contributions are welcome, whether you are fixing a bug, adding a feature, improving documentation, or reporting an issue. This page explains how to work within the project’s conventions so that review and merging go smoothly.

Reporting Issues

Open an issue at https://github.com/WSE-research/Solid-Hello-World-Frontend-React/issues/new using the User Story template. Fill in the description, acceptance criteria, and Definition of Ready fields. Incomplete issues are hard to estimate and easy to misinterpret.

For bugs, describe the expected behaviour, the actual behaviour, and the steps to reproduce.

Branching Strategy

All development targets the main branch. Create a feature branch from main for every piece of work, regardless of size.

Branch names follow this pattern:

<issue-number>-<short-description-in-kebab-case>

Examples:

42-context-menu-for-file-actions
57-grid-list-toggle-view
61-url-sync-and-deep-linking

Keeping branches small and focused makes review faster and reduces the risk of conflicts.

Commit Message Format

solid.drive uses Conventional Commits. Every commit message must start with a type prefix:

Type When to use

feat

A new user-facing feature

fix

A bug fix

refactor

Code restructuring with no behaviour change

test

Adding or updating tests

docs

Documentation only changes

chore

Build scripts, dependency updates, configuration

perf

Performance improvements

ci

CI/CD pipeline changes

Format:

<type>: <short imperative description>

<optional body, explain the why not the what>

Examples:

feat: add grid and list toggle to the file explorer

fix: resolve publisher WebID to display name in shared-with-me section

test: add e2e coverage for upload and delete flows

refactor: extract shared catalog naming logic into infrastructure/solid

Pull Request Process

  1. Open an issue first for anything non-trivial. Alignment before code saves everyone time.

  2. Fork the repository and create a branch from main following the naming convention above.

  3. Write tests for your changes. The project targets 80 % coverage; new code should not drop it.

  4. Run the full check suite before pushing:

    npm test
npm run lint

  5. Open a PR against main with a clear title and a summary of what changed and why.

  6. Address review feedback by pushing new commits; do not force-push during an active review.

  7. The PR is merged after approval and all CI checks pass.

💡
 Small, focused PRs are reviewed faster. If a feature is large, break it into logical phases and open one PR per phase.

Pre-Merge Checklist

Before requesting review, verify that:

  • ❏ All acceptance criteria from the linked issue are satisfied

  • ❏ New behaviour is covered by automated tests

  • ❏ npm test and npm run lint pass with no errors

  • ❏ No imports violate the layered architecture rules (see Architecture)

  • ❏ The manual QA checklist has been run for any flow that touches Solid Pod interactions

Clone this wiki locally