|
| 1 | +# Contributing to DiracX-Web |
| 2 | + |
| 3 | +### 1. Open an Issue |
| 4 | + |
| 5 | +!!! tip "Discussion First" |
| 6 | + Before making a pull request (PR), especially for non-trivial changes, please [open an issue](https://github.com/DIRACGrid/diracx-web/issues) to discuss your idea. This ensures that everyone is aligned on the proposed change. |
| 7 | + |
| 8 | +!!! info "Check Existing Issues" |
| 9 | + Before opening a new issue, please check if a similar issue already exists. If a similar issue exists, consider contributing to the discussion there instead. |
| 10 | + |
| 11 | +!!! success "Good First Issues" |
| 12 | + If you want to start contributing right away, check out the issues labeled with ["good first issue"](https://github.com/DIRACGrid/diracx-web/labels/good%20first%20issue). These are issues that are well-suited for newcomers to the project. |
| 13 | + |
| 14 | +### 2. Make Changes |
| 15 | + |
| 16 | +!!! info "Requirements" |
| 17 | + [Getting Started](../tutorials/getting_started.md) |
| 18 | + |
| 19 | +=== "Repository Setup" |
| 20 | + |
| 21 | + **Fork the Repository** |
| 22 | + : Start by forking the repository and creating a new branch for your work. Use a descriptive name for your branch that reflects the work you are doing. |
| 23 | + |
| 24 | +=== "Documentation" |
| 25 | + |
| 26 | + **Code Documentation** |
| 27 | + : Ensure that any code you write is well-documented. This includes: |
| 28 | + |
| 29 | + - Inline comments where necessary to explain complex logic |
| 30 | + - Updating or creating Storybook documentation if you are contributing to the `diracx-web-components` library |
| 31 | + - You can use tools like [ESLint](https://eslint.org/) and [Prettier](https://prettier.io/) to maintain code quality |
| 32 | + |
| 33 | +=== "Testing" |
| 34 | + |
| 35 | + **Component Testing** |
| 36 | + : Write tests for your stories to ensure they work as expected. Use [Jest](https://jestjs.io/) for unit testing and snapshot testing of your React components. |
| 37 | + |
| 38 | + **Application Testing** |
| 39 | + : Use [Cypress](https://www.cypress.io/) for end-to-end testing to simulate real user interactions and ensure your application behaves correctly. |
| 40 | + |
| 41 | + **Test Coverage** |
| 42 | + : Maintain good test coverage to ensure that your critical features are well-protected during updates. Tools like Jest provide [coverage reports](https://jestjs.io/docs/code-coverage) that help you identify untested parts of your code. |
| 43 | + |
| 44 | +=== "Accessibility" |
| 45 | + |
| 46 | + **Inclusive Design** |
| 47 | + : Make your application accessible to all users. Use semantic HTML, ARIA attributes, and test your application with different screen sizes and assistive technologies. |
| 48 | + |
| 49 | +!!! tip "Component Exports" |
| 50 | + If you create an export function or component in `diracx-web-components`, you must add it to the `index.ts` file and run `npm run build` inside `packages/diracx-web-components` to ensure the pre-commit hook passes. |
| 51 | + |
| 52 | +!!! warning "Breaking Changes" |
| 53 | + Don't forget to update the `packages/extensions` code if you integrate breaking changes in the `diracx-web-components` library. See [Managing the extension](manage_extension.md) for further details. |
| 54 | + |
| 55 | +### 3. Commit |
| 56 | + |
| 57 | +!!! info "Conventional Commits Required" |
| 58 | + All commits must follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. This ensures that commit messages are structured and consistent, which is important for automation and versioning. |
| 59 | + |
| 60 | +**Examples:** |
| 61 | +``` |
| 62 | +feat(ui): add new button component |
| 63 | +fix(api): handle null values in response |
| 64 | +docs(readme): update contributing guidelines |
| 65 | +``` |
| 66 | + |
| 67 | +!!! danger "CI Requirement" |
| 68 | + If your commit messages do not follow this convention, the Continuous Integration (CI) process will fail, and your PR will not be merged. Please ensure your commit messages are properly formatted before pushing. |
| 69 | + |
| 70 | +!!! note "Pre-commit Hooks" |
| 71 | + `Husky` is configured to run as a pre-commit script, executing tasks such as linting staged files to maintain code consistency with the codebase. |
| 72 | + |
| 73 | + |
| 74 | +### 4. Make a Pull Request (PR) |
| 75 | + |
| 76 | +- **Submit Your PR:** When you’re ready, submit your pull request. Please include a clear description of what your PR does and reference the issue number it addresses (if applicable). |
| 77 | +- **Review Process:** Your PR will be reviewed by project maintainers. Please be patient and responsive to any feedback you receive. |
| 78 | + |
| 79 | +### 5. Additional Notes |
| 80 | + |
| 81 | +- **Trivial Changes:** For minor changes like fixing typos, feel free to skip the issue creation step and go straight to making a PR. |
| 82 | +- **Stay Up-to-Date:** Make sure your branch is up-to-date with the latest changes in the main branch before submitting your PR. Use `git rebase` if necessary. |
0 commit comments