Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
174 lines (123 loc) · 5.9 KB

CONTRIBUTING.md

File metadata and controls

174 lines (123 loc) · 5.9 KB

Contributing to Shoutify

Thank you for your interest in becoming a contributor to Shoutify. We welcome all contributions, no matter how large or small. Please take a moment to review this document in order to make effective contributions.

Have a Question?

Have a question about Shoutify? Ask questions or feel free to talk about anything Shoutify related in our GitHub Discussions forum.

Discover a Bug?

Something not working as expected? Let's see if we can work together to get it resolved. If you believe you have discovered a bug, please open an issue on the GitHub repository and select the "Bug Report" template.

Open an issue

Missing Feature?

Would you like to see a new feature added to Shoutify? Let's discuss it! All features for Shoutify should begin as an Issue on the GitHub repository. Select the "Feature Request" issue template and engage with the community to come to a collective solution to the feature request.

Create a Feature Request

Contributing

Want to contribute to Shoutify? Great! We welcome all contributions no matter how large or small. Please begin by taking a look at the open issues and get involved in the conversation. We would be happy to assign you to an issue and help you get started.

Get started by reading the HACKING.md document, and come back here when you're ready to submit.

Submission Guidelines

Commit Conventions

This project strictly adheres to the conventional commits specification for creating human readable commit messages with appropriate automation capabilities, such as changelog generation.

Commit Message Format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(optional <scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Footer should contain a closing reference to an issue if any.

Breaking Change

Append a ! to the end of the type in your commit message to suggest a BREAKING CHANGE

<type>!(optional <scope>): <subject>
Type

Must be one of the following:

  • build: Changes that affect the build system or external dependencies (example scopes: npm, eslint, prettier)
  • ci: Changes to our CircleCI configuration
  • chore: No production code changes. Updates to readmes and meta documents
  • docs: Changes to the automated documentation or TSDoc comments
  • feat: A new feature
  • fix: A bug fix
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests
  • sample: A change to the samples

Submitting a Pull Request

After searching for potentially existing pull requests or issues in progress, if none are found, please open a new issue describing your intended changes and stating your intention to work on the issue.

Creating issues helps us plan our next release and prevents folks from duplicating work.

After the issue has been created, follow these steps to create a Pull Request.

  1. Fork the TechSquidTV/Shoutify repo.
  2. Clone your newly forked repository to your local machine.
  3. Create a new branch for your changes: git checkout -b fix/my-issue main
  4. Run npm install
  5. Implement your change with appropriate test coverage.
  6. Utilize our commit message conventions.
  7. Push all changes back to GitHub git push origin fix/my-issue
  8. In GitHub, send a Pull Request to shoutify:main

Thank you for your contribution!

After Your PR Has Been Merged

After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository:

  • Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:

    git push origin --delete fix/my-issue

  • Check out the main branch:

    git checkout main -f

  • Delete the local branch:

    git branch -D fix/my-issue

  • Update your main with the latest upstream version:

    git pull --ff upstream main

How To Issue a Release

For maintainers only

This is subject to change

When it is time to release a new version, follow the following steps.

  1. Ensure all relevant PRs have been merged into the main branch, awaiting "deployment".
  2. Review the commit history to determine the release type (major, minor, patch)
  3. On GitHub, create a new Release with the main branch as the target and specify the version number.
  4. Include the automatically generated release notes in the release description.

FAQ

Q. Why does my commit fail?

A. This project makes use of git commit hooks to automate pre-checking commits by linting, testing, and running prettier. If you would like to bypass these checks locally temporarily to save progress, ensure to add the --no-verify flag to your commit message.

A. Want the hooks enabled but they are still failing? Check to ensure you are using the right version of NodeJS but running nvm use in the directory.