Add a CONTRIBUTING document about mautic-cron-commands HOT 6 CLOSED

CONTRIBUTING.md

All Contributors Welcome

We define contributors as those who contribute to this project in any category at any level of contribution. This specification is, by definition, inclusive of all contributions.

We use the AllContributors 🤖 to automate acknowledging contributors to this project.

from mautic-cron-commands.

CONTRIBUTING.md

Pull Requests

It is recommended to keep your changes grouped logically within individual commits. Many contributors find it easier to review changes that are split across multiple commits. There is no limit to the number of commits in a pull request.

git add my/changed/files
git commit

ℹ️ Note:

Multiple commits in a pull request can be squashed to a single commit when they are merged

Commit message guidelines

A good commit message should describe what changed and why.

• Use the present tense ("add feature" not "added feature")
• Use the imperative mood ("move output to..." not "moves output to...")

We use semantic commit messages to streamline the release process.

Before a pull request can be merged, it must have a pull request title with a semantic prefix.
Having a consistent format allows us to automate CHANGELOG updates.

Examples of commit messages with semantic prefixes:

• docs: 📝 address the upgrade process
• feat: ✨ add command write:docs:forme
• fix: 🐛 lookup the correct parameter

from mautic-cron-commands.

CONTRIBUTING.md

Pull Requests

Commit message guidelines

Common prefixes

• feat: :sparkles: a new feature
• fix: :bug: a bug fix
• docs: :memo: documentation changes
• refactor: :art: a code change that neither fixes a bug nor adds a feature
• refactor: :rotating_light: a code change that does not affect the meaning of the code (linting)
• perf: :racehorse: a code change that improves performance
• test: :white_check_mark: adding or changing tests
• chore: :wrench: performing repository maintenance
• chore: ️️:tada: release :bookmark: 1.0.0
• ci: :green_heart: changes to our CI configuration files and scripts
• vendor: :arrow_up: bumping a dependency

💡 ProTip:

Other things to keep in mind when writing a commit message:

• The first line should:
  • contain a short description of the change (preferably 50 characters or less, and no more than 72 characters)
  • be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code, like function/variable names
• Keep the second line blank.
• Wrap all other lines at 72 columns.
• Reference issues and other pull requests liberally after the first line

from mautic-cron-commands.

CONTRIBUTING.md

Pull Requests

Commit message guidelines

Emoji

You are encouraged to include an applicable emoji in commit messages after the semantic prefix:

• ✨ :sparkles: when adding a feature
• 📝 :memo: when writing docs
• 🐛 :bug: when fixing a bug
• ✏️ :pencil2: when it's just a typo
• 🔥 :fire: when removing code or files
• 💥 :boom: when there is a Breaking Change
• 🎨 :art: when improving the format/structure of the code
• 🚨 :rotating_light: when removing linter warnings
• 💚 :green_heart: when fixing the CI build
• ✅ :white_check_mark: when adding tests
• 🔒 :lock: when dealing with security
• 🎉 :tada: when announcing a release 🔖 :bookmark:
• 🚀 :rocket: when deploying, or initiating a CI deployment
• 🔧 :wrench: when performing repository maintenance
• ⬆️ :arrow_up: when upgrading dependencies
• ⬇️ :arrow_down: when downgrading dependencies
• 🐎 :racehorse: when improving performance

Breaking Changes

A commit that has the text BREAKING CHANGE: at the beginning of its third line, or footer section, introduces a breaking change (correlating with Major in semantic versioning). A breaking change can be part of commits of any type.

e.g., a fix:, feat: & chore:

types would all be valid, in addition to any other type.

See conventionalcommits.org for more details.

from mautic-cron-commands.

CONTRIBUTING.md

Coding conventions

Start reading our code and you'll get the hang of it. We optimize for readability.
If in doubt, you have some simple options:

• stay faithful to the existing style
• just ask us
• look at the editorconfig settings in .editorconfig

TL;DR

TL;DWy
(didn't write yet)

Follow the guidelines in your IDE of choice (ie VS Code) from the most popular language extensions.

from mautic-cron-commands.

CONTRIBUTING.md

Coding conventions

PHP

WIP

error() {
printf '[%(%Y-%m-%dT%X)T]: %s\n' "$@" >&2
}

if ! do_something; then
error "Unable to do_something"
exit "${E_DID_NOTHING}"
fi

#!/usr/bin/env bash
#-*- coding: utf-8 -*-
#
# Perform hot backups of Oracle databases.

Final thoughts

This is open-source software.

• Consider the people who will read your code, and make it look nice for them.

  It's sort of like driving a car: perhaps you love doing donuts when you're alone, but with passengers, the goal is to make the ride as smooth as possible.

1. This is going to be a multi repo document ↩

from mautic-cron-commands.