Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Added contributing instructions and authors. #12
Conversation
added some commits
Jan 9, 2015
|
Please take a look @niemeyer |
niemeyer
reviewed
Jan 9, 2015
| +goamz Authors | ||
| +============= | ||
| + | ||
| +This file contains the list of the official goamz maintainers. |
niemeyer
Jan 9, 2015
Contributor
The official maintainers and the list of authors is not actually the same. It also seems unnecessary to have a list of official maintainers.. the point of contact should be the project itself and the mailing list. The maintainers should be watching those.
I suggest "dumbing down" this file to be a list of authors, people that contributed relevant code to the project.
niemeyer
reviewed
Jan 9, 2015
| + * [Fork](https://help.github.com/articles/fork-a-repo/) the go-amz/amz repository. | ||
| + * If you found a bug, please check the existing [issues](https://github.com/go-amz/amz/issues) to see if it's a known problem. Otherwise, [open a new issue](https://github.com/go-amz/amz/issues/new) for it. | ||
| + * Clone your forked repository locally. | ||
| + * Switch to the `v1` branch. |
niemeyer
Jan 9, 2015
Contributor
If you clone a non-v1 branch, the branch won't magically be there. That said, when you clone from the amz repository, because v1 is set as the development focus, that's what will be cloned:
$ git clone https://github.com/go-amz/amz
Cloning into 'amz'...
remote: Counting objects: 1552, done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 1552 (delta 14), reused 3 (delta 0)
Receiving objects: 100% (1552/1552), 359.52 KiB | 167.00 KiB/s, done.
Resolving deltas: 100% (1071/1071), done.
Checking connectivity... done.
$ cd amz
$ git branch
* v1
niemeyer
reviewed
Jan 9, 2015
| + * Be sure to test your code changes. | ||
| + * Push your feature branch to your fork. | ||
| + * Open a pull request with a description of your change. | ||
| + * Ask a maintainer for a code review. |
niemeyer
Jan 9, 2015
Contributor
This should not be needed. Maintainers should be watching the project for such pull requests.
niemeyer
reviewed
Jan 9, 2015
| + * If you found a bug, please check the existing [issues](https://github.com/go-amz/amz/issues) to see if it's a known problem. Otherwise, [open a new issue](https://github.com/go-amz/amz/issues/new) for it. | ||
| + * Clone your forked repository locally. | ||
| + * Switch to the `v1` branch. | ||
| + * Create a feature branch for your contribution. |
niemeyer
Jan 9, 2015
Contributor
Would be good to recommend keeping the branch as small as possible, and saying it's okay to send multiple requests often, to prevent people trying to merge 10k lines in one go and being surprised with a reject.
niemeyer
reviewed
Jan 9, 2015
| + * Reply to comments, fix issues, push your changes. Depending on the size of the patch, this process can be repeated a few times. | ||
| + * Once you get an approval and the CI tests pass, ask a maintainer to merge your patch. | ||
| + | ||
| +Becoming an official maintainer |
niemeyer
Jan 9, 2015
Contributor
I'd drop this section entirely. In most serious projects official maintainers merely become, transparently, because they are involved enough and it makes sense. An "official maintainer" badge pretty much never works, unless the project is changing hands.
dimitern
Jan 10, 2015
Member
I think at least for the sake of mentioning signing the CLA this should stay. Rephrased a bit though.
niemeyer
reviewed
Jan 9, 2015
| +not clear. | ||
| + | ||
| + * Commit early, commit often. | ||
| + * Before pushing your changes for the first time, use `git rebase -i v1` to minimize merge conflicts. Do not use `git pull v1`, use `git fetch` instead to avoid merging. |
niemeyer
Jan 9, 2015
Contributor
This requires a very intimate relation with git and revision control. I'd strongly suggest not asking people to do that in such a "newcomers" guideline. People that understand what rebase is and how it works internally don't need this guideline at all.
niemeyer
reviewed
Jan 9, 2015
| + | ||
| + * Commit early, commit often. | ||
| + * Before pushing your changes for the first time, use `git rebase -i v1` to minimize merge conflicts. Do not use `git pull v1`, use `git fetch` instead to avoid merging. | ||
| + * Rebase and squash small, yet unpushed changes. Let's keep the commit log cleaner. |
niemeyer
reviewed
Jan 9, 2015
| + * Commit early, commit often. | ||
| + * Before pushing your changes for the first time, use `git rebase -i v1` to minimize merge conflicts. Do not use `git pull v1`, use `git fetch` instead to avoid merging. | ||
| + * Rebase and squash small, yet unpushed changes. Let's keep the commit log cleaner. | ||
| + * Do not rebase commits you already pushed, even when in your own fork. Others might depend on them. |
niemeyer
reviewed
Jan 9, 2015
| +------------ | ||
| + | ||
| +Contributors are most welcome! | ||
| +Please have a look at [CONTRIBUTING.md](CONTRIBUTING.md) for instructions. |
niemeyer
reviewed
Jan 9, 2015
| +License | ||
| +------- | ||
| + | ||
| +goamz is licensed under [LGPLv3](LICENSE). |
niemeyer
Jan 9, 2015
Contributor
Suggest:
goamz is licensed under LGPLv3, but includes an exception that allows linking code statically.
See the [LICENSE](LICENSE) for details.
|
LGTM given the above notes. |
|
@niemeyer Thanks for the review! I've done all relevant suggestions and I think it's ready for merging. |
dimitern commentedJan 9, 2015
Added CONTRIBUTING.md with instructions for collaborators, AUTHORS.md with the list of maintainers, and updated the README.md slightly.