CONTRIBUTING.md

Contributing to <media-chrome>

• Questions
• Bugs and Issues
• Documentation Updates
• Feature Requests
• Submitting a Pull Request
• Merging a Pull Request
• Releasing

Questions

Have a question? Want to start a discussion? For now, you can simply Open a New Discussion, and choose a fitting category and title.

Bugs and Issues

If you think you've found a bug, make sure you review and fill out a Bug Report before starting any work. This will ensure for both yourself and the maintainers that the issue in question can be properly confirmed, reproduced, smoke tested, etc. Once done, if you want to try to fix the issue yourself, go ahead and follow our Submitting a Pull Request guide. Contributions are welcome and encouraged!

Documentation Updates

Our documentation update request requirements are similar to the requirements for Bugs and Issues.

Feature Requests

For feature requests, you can start by reviewing and filling out a Feature Request. Unlike bug fixes, Feature Requests will likely require more discussion from the maintainers, including whether or not it is consistent with our overall architectural goals, our timeline and priorities, and the like. Once done, assuming you've gotten a 👍 to work on the feature, go ahead and follow our Submitting a Pull Request guide.

Submitting a Pull Request

Before submitting a pull request, make sure you've reviewed and filled out an appropriate Issue. We recommend doing this before starting any work, just in case an issue already exists, or it's unlikely the maintainers will be able to review the PR because it e.g. lacks sufficient reproduction steps. In addition, we recommend the following:

1. We use conventional commits. Please try to prefix your commits according to the type of changes you're making, and try to be as descriptive as possible in your commit messages. For example:

• For Bug Fixes: fix: foo by bar
• For Features: feat: add video feat
• For Documentation Updates: docs: update audio copy

2. Make sure you base your branch off of the latest in main, e.g.

   git checkout -b my-fix-for-foo main

3. When issuing your Pull Request, be sure to Link it to the corresponding issue(s)

4. Add any additional comments to your PR's description that will help the reviewer(s), such as call outs, open questions, areas that merit extra attention, etc.

5. When addressing any feedback, you can simply add it as new commits.

6. We use a rebase strategy when merging PR branches into main. If your branch has merge conflicts, if possible, please try to resolve them by doing a git rebase onto main and then doing a git push --force-with-lease. For example:

   git fetch upstream
   git rebase --onto main your-old-base my-fix-for-foo
   ... resolve any conflicts
   git push --force-with-lease

   (See the git docs for more details on git rebase --onto)

Merging a Pull Request (maintainers only)

When you choose to squash and merge be sure to prefix the commit message with fix:, feat: or similar according to conventional commits.

Releasing (maintainers only)

Short version (I've done this before!)

1. Visit the GitHub Actions tab and select the "CD" action in the left sidebar.
2. Click the "Run workflow" dropdown and choose the correct Version on the main branch.
   • In the Use workflow from select box, make sure Branch: main is selected.
   • In the Version select box, choose the appropriate value:
     • If the commit messages in this release were written using the correct conventional commit style, select conventional.
     • If the commit messages aren't accurate, manually choose the correct semver version patch, minor, major.
3. When you're confident with your choices, click the green Run workflow button to start the release process.
4. After a few minutes, a new release will be published. This includes an NPM package, new version tags, and a GitHub release.

---

Long version (I need more context!)

This repo uses conventional commits and GitHub Actions for continuous deployment (CD).

If you're unfamiliar with conventional commits, it's a good idea to review the link above before continuing.

Here's a quick summary of how we use conventional commits in this repository:

• Commit messages prefixed with fix: will notify CD that the release is minimally a patch release.
• Commit messages prefixed with feat: will notify CD that the release is minimally a minor release.
• Commit messages containing BREAKING CHANGE in the footer will notify CD that the release is minimally a major release.
• All other conventional commits have no impact on the versioning.

Review commit messages since last release

To proceed with a release, you should be confident that the commits in your upcoming release accurately reflect the type of version that you intend to release.

Here's how you can review the commits you're about to release:

1. Visit https://github.com/muxinc/media-chrome/compare
2. In the base select box, choose the tag applied to the previous release. Keep main for the compare select box value.
3. Review the list of commits to see if they are appropriately using conventional commits.

Note: if you're uncertain about particular commits, you may want to reach out to the author of said commit(s) for clarity

Steps to release a new version

1. Visit the GitHub Actions tab and select the "CD" action in the left sidebar.

2. Click the "Run workflow" dropdown and choose the correct Version on the main branch.
   • In the Use workflow from select box, make sure Branch: main is selected.
   • In the Version select box, choose the appropriate value:
     • If the commit messages in this release were written using the correct conventional commit style, select conventional.
     • If the commit messages aren't accurate, manually choose the correct semver version patch, minor, major.
3. When you're confident with your choices, click the green Run workflow button to start the release process.
4. After a few minutes, a new release will be published. This includes an NPM package, new version tags, and a GitHub release.
5. That's it! Nice work.