Skip to content

Latest commit

 

History

History
87 lines (44 loc) · 3.37 KB

CONTRIBUTING.md

File metadata and controls

87 lines (44 loc) · 3.37 KB
Raw

How to Contribute

All contributions are welcome! This guide will get you up to speed with the contribution process for Gooey.

Some Caveats Up Front:

  • Opening a PR does not guarantee it will be merged
  • Feedback may take time
  • Merges may take time

Getting Started:

All bugs and non-trivial changes must have an associated issue. So, step one should be making sure that your issue doesn't already exist. If you find a relevant issue, feel free to add a comment with any additional details or problems specific to your use case. Otherwise, open a new issue and fill out the template in its entirety.

An exception to this rule is for any "trivial" change such as language additions, documentation fixes, typo corrections, etc.. no issue is required for these. Just include a good description / overview in your PR.

Development Overview

All development and pull requests should be made against the current release branch. Master is reserved for the last stable working version of the code. As such, it will often be outdated.

Release branches take the form of {semvar}-release. For example:

  • 1.0.2-release
  • 2.0.0-release

You can find the current release branch by checking out the branches page.

Making Changes:

  • Create a branch for your changes
    • Use the current release branch
    • Don't branch from master! This will cause you pain!
    • Ideal branch naming would reference the issue number it is resolving (e.g. issue-xxx-enabling-cool-feature ).
  • Group your commits into coarse feature-level chunks (preferably one) and reference the issue number in the message (e.g. "closes #322 - added cool feature XXX")
    • Make your commits about One Thing.
    • Avoid stream of consciousness style commits as they'll just be asked to be cleaned up during code review
  • Make sure you've added tests for your feature / bug fix
  • Make sure it works on both Python 2.7 and Python 3.x (this is often overlooked!)
  • Backwards compatibility must be honored

Pull Request Process

Pull Requests should be made against the current release branch. You can find the current release branch here.

A good PR should hit these essentials.

Basic Checklist:

  • Works on both Python 2.7 & Python 3.x
  • Commit message includes the relevant issue number
  • Bug fix / feature has associated tests
  • README.md is updated (if relevant)
  • PR has summary of the change and links to the detailed issue.

Super Cool Person Above and Beyond Checklist Additions:

  • A sister commit in the Examples Repo was created demonstrating your new feature

Code of Conduct

None. Use your best judgement.

Grumpy Stuff:

  • Please do not email me directly to ask why your PR hasn't been merged
  • Please do not email me directly to ask why your issue hasn't been addressed.

The answer will always be some stock variant of (1) I'm just a guy, (2) I work on this for free (3) It's not a priority at the moment, (4) yes, I feel guilty all the time, (5) some weekends I just want to play a video game or something.

Worth a read.