3.4 KiB
Contributing
We love pull requests from everyone. By participating in this project, you agree to abide by our code of conduct.
Getting Started
- Make sure you have a GitHub account.
- Open an issue to simply ask a question or request a new feature.
- Search for similar issues with the ERROR MESSAGE you are exeriencing.
- If one doesn't exist, open a new issue
- Clearly describe the issue including steps to reproduce when it is a bug.
- Include the earliest version of
mas
that you know has the issue. - Include your macOS version.
Making Changes
- Fork the repository on GitHub.
- Cone your fork
git clone git@github.com:your-username/mas.git
- Create a topic branch from where you want to base your work.
- This is usually the
master
branch. - To quickly create a topic branch based on
master
, rungit checkout -b awesome-feature master
- Please avoid working directly on the master branch.
- Make commits of logical units.
- This is usually the
- Run script/format before committing your changes. Fix anything that isn't automatically fixed by the linters.
- Push your topic branch to your fork and submit a pull request.
Some things that will increase the chance that your pull request is accepted:
- Write tests. (Tests target is still in progress)
- If you need help with tests, feel free to open a PR in the meantime and just ask for some help.
- Add "[WIP]" to the title of your PR to indicate that it's not ready to be merged.
- Follow our style guide.
- Write a good commit message.
- Including appropriate emoji in the first line of commit messages is fun 😉.
Becoming a Contributor
Once you have had a few PRs accepted, if you are interested in joining the @mas-cli/contributors team to help with the issue/PR backlog and even release new versions of this project, open a new issue titled "Add Contributor: @YourGitHubUsername", with a brief message asking to join the team.
This project was created by @argon, who is unable to continue contributing to this project, but must remain an owner. By becoming a contributor, you agree to the terms in #47.
Branching and Releases
- This project follows trunk-based development, where
master
is our trunk. - Release commits will be tagged in the format:
v1.2.3
. - Once releases are tagged, high-level release notes are published on the releases page.
See GitHub's post on creating Contributing Guidelines if you would like to set up something like this for your projects.