Repository navigation
How to contribute changes? #81
Description
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/]
Activity
graysonarts commentedon Oct 27, 2016
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 commentedon Oct 27, 2016
@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 commentedon Oct 27, 2016
Oh yay! Every time I turn around you are taking care of things for me. 🤘
t8y8 commentedon Nov 1, 2016
@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 commentedon Nov 1, 2016
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 commentedon Nov 1, 2016
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 testin 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 commentedon Jan 6, 2017
I think we've got a solid dev guide (and contributors.md) now and most of this is documented.
Closing this out :)