Pod Monster is a project primarily maintained by @atdrago and is currently transitioning to open source. Since it's still early, you may encounter a few rough edges when attempting to contribute. This document's purpose is to try to make the process as clear and easy as possible.
Pod Monster has adopted the Contributor Covenant as its Code of Conduct, and we expect project participants to adhere to it. Please read the full text so that you can understand what actions will and will not be tolerated.
All work on Pod Monster happens directly on GitHub. The main contributor to the project is @atdrago. All other contributors are expected to fork the repository, create a branch, and send pull requests to the main branch which will go through a pull request review process by @atdrago and/or any other primary maintainers.
Pod Monster is currently in its alpha phase. All commits to the main branch go directly to production and are available to end users immediately. The project's version is never incremented during this process.
Once Pod Monster leaves its alpha phase, the version will be incremented based on the rules in the Semantic Versioning specification.
All commits that land on the main branch and PR titles are expected to follow the Conventional Commits specification, and the message should be in imperative mood. In general, you should be able to put your commit message into the blank space in the following sentence, and it should make sense: "If I merge this PR, it will _." For example, if I added a "Subscribe" button to each search result item, I may be tempted to make my commit message "Added subscribe button to search result items", but completing the above sentece with this commit message will not make sense: "If I merge this PR, it will added subscribe button to search result items". Instead, "Added" should be changed to "Add", like so: "Add subscribe button to search result items", and now this sentence is easier to read: "If I merge this PR, it will add subscribe button to search result items"
Below is a template and some examples to use when writing acceptable commit messages.
Note that commits are easy to squash together and their messages easy to change, so don't worry too much about getting this correct on your first couple of PRs.
type(scope): Short specific message describing the change
feat(search): Add subscribe button to search results
fix(player): Ensure video element changes when src changes
chore(deps): Bump react-query from 3.34.2 to 3.34.4
This project uses 4 primary commit types:
- docs - A change to documentation
- fix - A change that fixes something
- feat - A change that is user-facing
- chore - A change that is not user-facing
It is generally fine to leave out commit scope, but if specified it should be as short as possible and probably falls into one of the following:
- deps - Dependency updates
- deps-dev - Development dependency updates
- ci - Anything involving CI, including changes in any GitHub workflows
- player - Changes to the media player
- search - Changes to the main page
- feed - Changes to the feed page
- episode - Changes to the episode page
- about - Changes to the about page
- settings - Changes to the settings page
- artwork - Changes to how artwork is handled
Submit all changes directly to the main branch. We don't use separate branches for development or for upcoming releases. Code that lands in main goes directly to production, and as such may take a long time to get merged.
We are using GitHub Issues for our public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn't already exist.
The best way to get your bug fixed is to provide a reduced test case.
Please use GitHub Issues to report all security issues. Please do not add any sensitive or potentially sensitive information in a GitHub Issue. If it is absolutely necessary to include sensitive information as part of the bug report, please email the main project maintainer directly at atdrago@gmail.com with the subject line "Pod Monster Security", and reference the GitHub Issue within the body for further instructions.
If you intend to change the user interface, or make any non-trivial changes to the implementation, we recommend filing an issue. This lets us reach an agreement on your proposal before you put significant effort into it.
If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend to file an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue.
Working on your first Pull Request? You can learn how from this free video series:
How to Contribute to an Open Source Project on GitHub
If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you intend to work on it so other people don't accidentally duplicate your effort.
If somebody claims an issue but doesn't follow up for more than two weeks, it's fine to take it over but you should still leave a comment.
The core team is monitoring for pull requests. We will review your pull request and either merge it, request changes to it, or close it with an explanation.
Before submitting a pull request, please make sure the following is done:
- Fork the repository and create your branch from
main. - Make sure you are running Node v16+
- Run
npm installin the repository root. If you've fixed a bug or added code that should be tested, add tests!Not required until other tests are added.- Make sure the linter passes (
npm run lint) - Make sure the build passes (
npm run build) - Make sure the code is formatted (
npm run format)
In general, all changes related to formatting or linting should be caught by Prettier or ESLint prior to the pull request being made, however there are automatic checks that happen for every PR as well. If a human reviewer requests a stylistic (formatting or linting) change to a PR, a suitable linting or formatting rule should be agreed upon and be added to the appropriate configuration file, or otherwise should not be requested.
We use an automatic code formatter called Prettier and recommend that you use an extension to take care of formatting code for you on save. If you don't have this setup, please run npm run format after making any changes to the code.
Then, our linter will catch most issues that may exist in your code.
You can check the status of your code styling by simply running npm run lint.
By contributing to React, you agree that your contributions will be licensed under its MIT license.
This guide to contributing is adapted heavily from React's How to Contribute guide.