Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
108 lines (73 loc) · 4.74 KB

CONTRIBUTING.md

File metadata and controls

108 lines (73 loc) · 4.74 KB
Raw

Contributing to mistica-web

Thank you for your interest in Mística. You can contribute to this project in several ways:

You can contact maintainers at the Mística Teams Channel. Don't hesitate to ask any questions and share your ideas

Pull Requests

We would love to accept your Pull Requests but please, before starting your development, create an issue.

PR Title - Conventional commit standard

PR title must follow the Conventional Commits format:

<type>(<scope>): <subject>
  • type: the kind of change (see the allowed subset below).
  • scope: the affected component name (for example TextField, Dialog). For internal changes that do not touch a component, use Chore as the scope.
  • subject: a concise, imperative description of the change.
  • Add the AI label when the code was written by an AI agent.

Allowed types (the supported subset)

Conventional Commits defines many types, but this repository intentionally supports only a subset. The allowlist is enforced by the validate-pr-title job in .github/workflows/ci.yml:

  • fix
  • feat
  • chore
  • revert

PR Description

Concise summary of the problem and fix, ending with Ref: <ISSUE-ID>;

Reviewers

Always add the @Telefonica/mistica-web-reviewers team as a reviewer to every PR.

Fork PRs — preview deployment

PRs opened from a fork cannot access repository secrets, so CI and the preview deployment do not run automatically. The process requires a maintainer to explicitly approve each step:

  1. A maintainer approves the CI run on the PR so the standard checks execute against the fork's code.
  2. A maintainer reviews the PR and adds the safe-to-deploy label. This captures the exact commit SHA at that moment and triggers the deployment workflow.
  3. The triggered workflow post a link to the workflow run, which a maintainer has to approve. This approval gate is required before any secrets are exposed.
  4. Once approved, the preview is deployed against the pinned commit SHA. The deployment URL is printed in the workflow run logs.

[!IMPORTANT] If you push new commits to your branch after the safe-to-deploy label is added, the deployment will fail with a SHA mismatch. A maintainer must remove the label and add it again to re-trigger the deployment for the new commits.

Bug reports

If something is broken or not working as expected, let us know!

🐛 Open a Bug issue

Feature requests (no UI/UX changes)

If you need additional functionality, support a new use case, improve a component API...

🚧 Open a Feature Request issue

Important: Your feature request should not include UI or UX changes, only implementation details, because those kind of changes must be evaluated, approved and documented by the Design Core Team (see New component proposals or UI/UX changes section).

Documentation and help requests

Is something in our documentation not well explained? Do you need help using a component? Should we create a new Storybook story as example?

📘 Open an Documentation issue

New component proposals or UI/UX changes

Adding a new component to the Mística Design System or updating the UI/UX of an existing one requires to follow a process where the component and its use cases will be evaluated by the Design Core Team.

Share your ideas at the Mística Teams Channel or open an issue in the main Mistica Repository