Skip to content

Latest commit

 

History

History
151 lines (91 loc) · 7.2 KB

CONTRIBUTING.md

File metadata and controls

151 lines (91 loc) · 7.2 KB

Contributing to t3kit

Welcome, and thank you for your interest in contributing to t3kit

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

❓If you have a question or need a Support

Do not open issues for general support questions as we want to keep t3kit GitHub issues for bug reports and feature requests. t3kit Slack channel is a much better place to ask questions and get support.

To save your and our time, we will regularly close all issues that are requests for general support and redirect people to t3kit Slack.

🐞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 t3kit 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 our t3kit 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 duplicates - 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.
  • Check documentation about Pull Request on Github

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.

1. Make sure that you have the correct required dependencies

2. Code style

Editor config

PHP, TypoScript, Yaml

JS

CSS

Shell scripts

  • Use shellcheck static analysis tool for shell scripts

Dockerfile

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

t3kit supports 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
  • Also, it is possible to redefine it on a project base like in this example

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.