Kumoss
prerelease Prerelease stable Latest
↑↓ navigate · ↵ select · esc close
Kumoss
Kumoss
prerelease Prerelease stable Latest

Contributing

Sign the Contributor License Agreement, follow the code of conduct, and submit a pull request that passes Kumoss's checks.

Thank you for your interest in contributing to Kumoss. Any contribution is valued and appreciated; the guidelines below keep the project collaborative and respectful. For the local development loop — running the stack, the test suites, type checking, and linting — see Development.

Prerequisites

  • Before contributing code, sign the Contributor License Agreement (CLA). Instructions are at InditexTech/foss.

  • By participating in the project you agree to abide by the rules and principles set out in the code of conduct. Kumoss adheres to the general Inditex Tech Code of Conduct; direct any inquiry about it to oso@inditex.com.

  • Check existing issues and pull requests before starting work, to avoid duplication. If you take on an existing issue, comment on it so other contributors know it is in progress.

  • Discuss and gather feedback from the community before making significant changes to the project’s structure or architecture.

How to contribute

  1. Open an issue to discuss and gather feedback on the feature or fix you wish to address. Security vulnerabilities are the exception: report them through the disclosure submission program as described in the security policy, never through a public issue.

  2. Fork the repository and clone it to your local machine.

  3. Create a new branch to work on your contribution: git checkout -b your-branch-name.

  4. Make the necessary changes in your local branch, following Development to run the stack and its checks.

  5. Ensure that your code follows the established project style and formatting guidelines.

  6. Perform testing to ensure your changes do not introduce errors.

  7. Make clear and descriptive commits that explain your changes.

  8. Push your branch to the remote repository: git push origin your-branch-name.

  9. Open a pull request describing your changes and linking the corresponding issue.

  10. Await comments and discussions on your pull request. Make any necessary modifications based on the feedback you receive.

  11. Once your pull request is approved, your contribution is merged into the main branch.

Pull requests

Fill in the pull-request template (.github/PULL_REQUEST_TEMPLATE.md) and link the issue it addresses. Include UI screenshots for visible changes. Document any new changes or features you add, so other contributors and users understand your work and its purpose.

Keep the commit history clean and organized: divide your changes into logical, descriptive commits. Commit subjects must follow the Conventional Commits Specification (for example fix(core): release session lock); CI rejects other subjects. Sign your commits (git commit -S) — signing is required by policy and checked in review, not enforced by any CI workflow.

Every new file starts with an SPDX header following the REUSE Specification (SPDX-FileCopyrightText: 2026 INDUSTRIA DE DISEÑO TEXTIL S.A. (INDITEX S.A.) and SPDX-License-Identifier: Apache-2.0). CI runs the REUSE check on every pull request, alongside Repolinter and the Conventional Commits check above.