- Edit this page + Edit this page Submit an issue

diff --git a/docs/docs/dev-guide.md b/docs/docs/dev-guide.md index cd6bfee..b975f6e 100644 --- a/docs/docs/dev-guide.md +++ b/docs/docs/dev-guide.md @@ -3,17 +3,21 @@ title: Developer Guide layout: docs --- -### Making your first patch +## Submitting your first patch -1. Make sure you've signed the CLA +1. Make sure you have [signed the CLA](http://tableau.github.io/#contributor-license-agreement-cla) -1. Clone the repo +1. Fork the repository. + + We follow the "Fork and Pull" model as described [here](https://help.github.com/articles/about-collaborative-development-models/). + +1. Clone your fork: ```shell - git clone http://github.com/tableau/document-api-python + git clone http://github.com//document-api-python ``` -1. Run the tests to make sure everything is peachy +1. Run the tests to make sure everything is peachy: ```shell python setup.py test @@ -21,33 +25,44 @@ layout: docs 1. Set up the feature, fix, or documentation branch. - It is recommended to use the format [issue#]-[type]-[description] (e.g. 13-fix-connection-bug) + It is recommended to use the format issue#-type-description (e.g. 13-fix-connection-bug) like so: ```shell git checkout -b 13-feature-new-stuff ``` -1. Code and Commit! +1. Code and commit! + + Here's a quick checklist for ensuring a good pull request: + + - Only touch the minimal amount of files possible while still accomplishing the goal. + - Ensure all indentation is done as 4-spaces and your editor is set to unix line endings. + - The code matches PEP8 style guides. If you cloned the repo you can run `pycodestyle .` + - Keep commit messages clean and descriptive. + If the PR is accepted it will get 'Squashed' into a single commit before merging, the commit messages will be used to generate the Merge commit message. - Here's a quick checklist for ensuring a good diff: +1. Add tests. - - The diff touches the minimal amount of files possible while still fufilling the purpose of the diff - - The diff uses Unix line endings - - The diff adheres to our PEP8 style guides. If you've cloned the repo you can run `pycodestyle .` + All of our tests live under the `test/` folder in the repository. + We use `unittest` and the built-in test runner `python setup.py test`. + If a test needs a static file, like a twb/twbx, it should live under `test/assets/` -1. Add Tests +1. Update the documentation. -1. Update Documentation + Our documentation is written in markdown and built with Jekyll on Github Pages. All of the documentation source files can be found in `docs/docs`. - Our documentation is written in markdown and built with [Mkdocs](http://www.mkdocs.org). More information on how to update and build the docs can be found [here](#updating-documentation) + When adding a new feature or improving existing functionality we may ask that you update the documentation along with your code. + + If you are just making a PR for documentation updates (adding new docs, fixing typos, improving wording) the easiest method is to use the built in `Edit this file` in the Github UI -1. Run the tests again and make sure they pass! +1. Submit to your fork. -1. Submit to your fork +1. Make a PR as described [here](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) against the 'development' branch. -1. Submit a PR +1. Wait for a review and address any feedback. + While we try and stay on top of all issues and PRs it might take a few days for someone to respond. Politely pinging the PR after a few days with no response is OK, we'll try and respond with a timeline as soon as we are able. -1. Wait for a review, and address any feedback. +1. That's it! When the PR has received :rocket:'s from members of the core team they will merge the PR

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy

{{ page.title }}