How to contribute changes? #81
Comments
|
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. |
|
@RussTheAerialist I'm working on a 'devguide' that could be a good place to address this as well: Jared and I are just trying to agree on a docs build-and-test pipeline (and get it working) |
|
Oh yay! Every time I turn around you are taking care of things for me. 🤘 |
|
@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 |
|
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/ |
|
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 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 |
|
I think we've got a solid dev guide (and contributors.md) now and most of this is documented. Closing this out :) |
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/]
The text was updated successfully, but these errors were encountered: