Skip to content

Latest commit

 

History

History
143 lines (90 loc) · 6.57 KB

CONTRIBUTING.md

File metadata and controls

143 lines (90 loc) · 6.57 KB
Raw

Contributing to Resultify Hubspot projects

Welcome, and thank you for your interest in contributing

As a contributor, here are the guidelines we would like you to follow:

❓If you have a question or need a Support

Open issues with label question

🐞Add a Bug report

If you find a bug in the code or a mistake in the documentation, you can help us by submitting an issue to particular repository, or even better, you can submit a Pull Request with a fix.

🚀Add a new Feature

You can request a new feature by submitting an issue to the repository. If you would like to implement a new feature, please submit an issue with a proposal for your work first, to be sure that we can use it. Please consider what kind of change it is:

  • For a Major Feature, first open an issue and outline your proposal so that it can be discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
  • Small Features can be crafted and directly submitted as a Pull Request.

Submission Guidelines

Submitting an Issue

Before you submit an issue please check that you've considered the following steps:

  • Add a single issue per problem
  • Check duplicate - use the search feature to ensure that the problem hasn't been reported before.
  • Check dependencies - make sure you're on the right version of dependencies.
  • Check Browsers and devices
  • Use Issue templates - add a new issue by filling out the issue template.

Unfortunately, we are not able to investigate/fix bugs without a minimal reproduction, so if we don't hear back from you we are going to close an issue that doesn't have enough info to be reproduced.

Submitting a Pull Request

Before you submit your Pull Request (PR) please check that you've considered the following steps:

  • ❗️Please ask first before embarking on any significant pull request, otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project. Create an Issue to discuss potential big PR.
  • Search in GitHub for an open or closed Pull Request that relates to your submission.
  • Provide plenty of context and reasoning around your changes, to help us merge quickly.
  • Follow our Coding Rules
  • Follow our Commit message conventions
  • Close related issue in PR header message using GitHub keywords.
  • If your PR gets out of date, we may ask you to rebase as you are more familiar with your changes than we will be.
  • If your PR fail on CI tests, we may ask you to fix it.

Coding Guidelines

❗️ This part is quite important. If some of these rules are missed, you will not pass the CI test and will not be able to contribute. This is not to add complexity, but to maintain the quality of the code at a good level in the long run.

2. Code style

Editor config

JS

CSS

Class Naming convention

  • We follow BEM with some modifications
  • Class Naming rules:
    • Names are written in lowercase Latin letters.
    • The block name defines the namespace for its elements and modifiers. [card]
    • Words are separated by a hyphen (-). [card-block]
    • The element name is separated from the block name by a double underscore (__). [card-block__text-element]
    • The modifier name is separated from the block or element name by two dashes (--). [card-block__text--full-width]
    • Every block or element can have an external and|or internal wrapper separated by one underscore (_). [card-block_wrp, card-block_internal-wrp]

3. GIT

Commit Message Guidelines

Git message

  • Use the imperative, present tense: "change" not "changed" or "changes"
  • don't capitalize the first letter
  • no dot (.) at the end

Labels

  • Please use semantic labels for your messages, but if commit message is not very important, you can skip the label.

  • ❗️Only commit with label will be added in CHANGELOG file, that's why it is important to use predefined labels on your commits.

    • [FEATURE] - A new feature
    • [BUGFIX] - A bug fix
    • [TASK] - Any task, which is not a new feature or bugfix
    • [TEST] - Adding/updating tests and CI config
    • [DOC] - Documentation only changes/updates
    • [WIP] - Work in progress tag, should not be present when creating pull requests
    • [!!!] - Breaking Changes

  • ❗️Important: Commit label must be only one, except if it Breaking Changes, then we will need to add "Breaking Changes" label [!!!] at front.

    • For example (Breaking Change):
        [!!!][BUGFIX] change default CSS styling for Text and Image CE

Browsers and Devices

We support the latest and popular browser versions of each major mobile and desktop platforms.

We are using Can I Use data and Browserslist plugin to manage and define the target browsers list

  • Here (check browserslist) you can always find an up-to-date list of supported browsers

Code of Conduct

This project has a Code of Conduct. By interacting with this repository, organization, or community you agree to abide by its terms.