Skip to content

Latest commit

 

History

History
73 lines (37 loc) · 3.66 KB

CONTRIBUTING.md

File metadata and controls

73 lines (37 loc) · 3.66 KB
Raw

Contributing

Thank you for checking out our Data Flows (Prefect) work. We welcome contributions from everyone! By participating in this project, you agree to abide by the Mozilla Community Participation Guidelines.

Asking questions / receiving updates

Finding Bugs & Filing Tickets

If you've found a bug, or have a feature idea that you you'd like to see, follow these simple guidelines:

  • Pick a thoughtful and concise title for the issue (ie. not Thing Doesn't Work!)

  • If you can reproduce the bug, give a step-by-step recipe

  • Include stack traces from the console(s) where appropriate

  • Screenshots and screen recordings welcome!

  • When in doubt, take a look at some existing issues and emulate

Contributing Code

When you have some code written, you can open up a Pull Request, get your code reviewed, and see your code merged into the codebase.

Setting up your development environment

Please review the README.md for instructions on setting up your development environment, installing dependencies and running tests.

Creating Pull Requests

You have identified the bug, written code and now want to get it into the main repo using a Pull Request.

All code is added using a pull request against the main branch of our repo. Before submitting a PR, please go through this checklist:

  • Fill out the pull request template as outlined

  • Make sure your PR will merge gracefully with the main branch at the time you create the PR, and that your commit history is 'clean'

Understanding Code Reviews

You have created a PR and submitted it to the repo, and now are waiting patiently for you code review feedback. One of the projects module owners will be along and will either:

  • Make suggestions for some improvements

  • Give you a thumbs up in the comments section, indicating the review is done and the code can be merged

Typically, you will iterate on the PR, making changes and pushing your changes to new commits on the PR. When the reviewer is satisfied that your code is good-to-go, you will get the coveted R+ comment, and your code can be merged. If you have commit permission, you can go ahead and merge the code to master, otherwise, it will be done for you.

Our project prides itself on its respectful, patient and positive attitude when it comes to reviewing contributors' code, and as such, we expect contributors to be respectful, patient and positive in their communications as well.

Writing Good Git Commit Messages

We like this overview by Chris Beams on "How to Write a Git Commit Message".

The tl;dr is:

  1. Separate subject from body with a blank line

  2. Limit the subject line to 50 characters

  3. Capitalize the subject line

  4. Do not end the subject line with a period

  5. Use a verb to start your subject line (Add, Remove, Fix, Update, Rework, Polish, etc.)

  6. Wrap the body at 72 characters

  7. Use the body to explain what and why vs. how