GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Need to make it as easy as possible to get started contributing to boto. Point out some resources on how GitHub and forking works. Briefly walk them through forking, creating a branch in their fork, making the changes, pushing, and doing a pull request. Refer to GitHub's many resources so we don't get stuck maintaining that portion.
For docs, let them know what packages are required (Sphinx and I think M2Crypto), show them the Sphinx doc index. Point out the file structure of our docs. Show them how to compile docs.
Coding standards. Spaces, naming conventions, the maintaining of backwards compatibility. Docs and unit tests where possible.
Any other ideas?
Coding standards, i.e. "spaces instead of tabs", and any naming conventions we follow, as well as making sure it's clear that it needs to maintain backwards compatibility (including order of parameters)
Good idea, added to the issue.
I'll mull it over the weekend. While you or someone might explain the more technical aspects of Git, I can do a mental rundown to find common stumbling blocks.
IMO there are plenty of resources on Git, github, and even Python coding standards (e.g. PEP 8). While we can add in our own flavor to this information, I think it would be more effective for us to write documentation about how boto actually works behind the scenes and the structure of various boto components. One thing to do is to identify 2-3 bugs that have been resolved and write a guide that would walk someone through the steps of:
@victortrac what you suggest could be a document of its own right. I believe what @gtaylor meant was for someone relatively new to Github, python and boto, etc. how they can get involved. They might not necessarily want to (or know how) bug hunt, but they might be interested in other aspects: whether it's just documentation or perhaps they want to add test cases or an AWS mocking framework. This won't be geared toward someone who's well versed in AWS/boto/python, but more for the "casual" end user who might be compelled to pitch in.
@rdodev Yeah, I think they are separate documents, and both are useful. But what I'm suggesting is that there are already a variety of good general-purpose github contributing guides and that maybe our time would be more effectively spent writing a document more specific to boto (as a first pass). However, any additional documentation is a good, so I'll try to help out with any effort put forth.
@victortrac I feel pretty uncomfortable with pointing people at a handful of git/github docs and saying "Go", so we'll definitely include the basics in the outline on the issue. We can point to said docs as resources, but I'd like to have almost everything they need to get their first pull request submitted available in the boto docs. That is the lowest barrier to entry we can provide.
There are also different kinds of contributors. Some may not be interested at all in fixing bugs in the actual Python code. Some way just want to help with docs, and etc. So while it's definitely helpful to walk through a bug, I think it is, as you've said, a separate doc. Might be good to open another issue and refer to it from here so we get the link in.
There's now several docs on this: The main contributing guide (https://github.com/boto/boto/blob/develop/docs/source/contributing.rst) as well as the GH contributing guidelines (https://github.com/boto/boto/blob/develop/CONTRIBUTING). Pull requests that flesh out areas that need more attention would be much appreciated.
Merge pull request #554 from JordonPhillips/get-available-subresources
Add get_available_subresources to Resources