How to contribute changes?

[geordielad]

Would it help new contributors if we stated the the code contribution model is based on a Fork and Pull model? I am new to contributing so this might be redundant information for more experienced developers but I notice that there is another approach (Shared Repo) described here: [https://help.github.com/articles/about-collaborative-development-models/]

[graysonarts]

Agreed. I'll see if I can update the contributing document to reflect our desired contribution model. The Fork/Pull Request model is pretty standard with open source, and I prefer it over the Shared Repo approach.

The shared repo approach is great if you have a small team and a small set of contributors. Because we want our projects to be open to anyone to contribute, the fork/pull works best because it does not tie contributions to write access to the repo.

I'll push an updating to the contributing.md file with appropriate links.

[t8y8]

@RussTheAerialist I'm working on a 'devguide' that could be a good place to address this as well:
https://t8y8.github.io/document-api-python/docs/dev-guide

Jared and I are just trying to agree on a docs build-and-test pipeline (and get it working)

[graysonarts]

Oh yay! Every time I turn around you are taking care of things for me. 🤘

[t8y8]

@geordielad can you take a look at https://github.com/tableau/document-api-python/blob/development/docs/docs/dev-guide.md and let me know if you think that covers it?

We'll add those docs to this repo soon

[geordielad]

I like it.

At section #5 - Do we need to actually suggest raising an issue as a placeholder for discussions? I think an earlier doc gives that guidance and it makes a lot of sense to create an issue.

Is is going to be obvious that the project is targeted at multiple Python versions? I am not even sure how to code to support 2.7+ and 3.x but I see that the tests run for multiple versions (after syncing). I thought running tests in step #4 was going to make it obvious but they do not. Not to me anyway.

Its funny, I went back to several github tutorials and none of them seem to describe our model exactly. I guess we are using master as the release branch so I assume that's why we have a dev branch and that's the one to to the PR to because we are all are working on the 'next' version. I am now thinking of of our model as Fork Branch Pull. This blog seems to get close to the way we want people to work: http://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/

[t8y8]

We can update #5 to talk about filing an issue. I don' think it's necessarily absolute policy that everything must have an issue first (At least, I haven't always done so).

It's pretty much the norm these days for all projects to be 2.7 and 3.3+, and TravisCI runs the tests across all the supported versions. We could include a line about testing on multiple versions (it's just running python setup.py test in the right venvs for most users.

I don't really want to add tox or anything crazy like that to the test suite. I like that everything is clone-and-go, and with what we're working on it shouldn't be much of a problem to code and test against 2.7 OR 3 and then let Travis get the rest.

As an example, @RussTheAerialist works in 2.7 and I work in 3.5 and we've been mostly fine

[t8y8]

I think we've got a solid dev guide (and contributors.md) now and most of this is documented.

Closing this out :)