1# Contributing to graphql
2
3This document is based on the [Node.js contribution guidelines](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md)
4
5## Chat room
6
7[]
8(https://gitter.im/graphql-go/graphql?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
9
10Feel free to participate in the chat room for informal discussions and queries.
11
12Just drop by and say hi!
13
14## Issue Contributions
15
16When opening new issues or commenting on existing issues on this repository
17please make sure discussions are related to concrete technical issues with the
18`graphql` implementation.
19
20## Code Contributions
21
22The `graphql` project welcomes new contributors.
23
24This document will guide you through the contribution process.
25
26What do you want to contribute?
27
28- I want to otherwise correct or improve the docs or examples
29- I want to report a bug
30- I want to add some feature or functionality to an existing hardware platform
31- I want to add support for a new hardware platform
32
33Descriptions for each of these will eventually be provided below.
34
35## General Guidelines
36* Reading up on [CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments) would be a great start.
37* Submit a Github Pull Request to the appropriate branch and ideally discuss the changes with us in the [chat room](#chat-room).
38* We will look at the patch, test it out, and give you feedback.
39* Avoid doing minor whitespace changes, renaming, etc. along with merged content. These will be done by the maintainers from time to time but they can complicate merges and should be done separately.
40* Take care to maintain the existing coding style.
41* Always `golint` and `go fmt` your code.
42* Add unit tests for any new or changed functionality, especially for public APIs.
43* Run `go test` before submitting a PR.
44* For git help see [progit](http://git-scm.com/book) which is an awesome (and free) book on git
45
46
47## Creating Pull Requests
48Because `graphql` makes use of self-referencing import paths, you will want
49to implement the local copy of your fork as a remote on your copy of the
50original `graphql` repo. Katrina Owen has [an excellent post on this workflow](https://splice.com/blog/contributing-open-source-git-repositories-go/).
51
52The basics are as follows:
53
541. Fork the project via the GitHub UI
55
562. `go get` the upstream repo and set it up as the `upstream` remote and your own repo as the `origin` remote:
57
58```bash
59$ go get github.com/graphql-go/graphql
60$ cd $GOPATH/src/github.com/graphql-go/graphql
61$ git remote rename origin upstream
62$ git remote add origin git@github.com/YOUR_GITHUB_NAME/graphql
63```
64All import paths should now work fine assuming that you've got the
65proper branch checked out.
66
67
68## Landing Pull Requests
69(This is for committers only. If you are unsure whether you are a committer, you are not.)
70
711. Set the contributor's fork as an upstream on your checkout
72
73 ```git remote add contrib1 https://github.com/contrib1/graphql```
74
752. Fetch the contributor's repo
76
77 ```git fetch contrib1```
78
793. Checkout a copy of the PR branch
80
81 ```git checkout pr-1234 --track contrib1/branch-for-pr-1234```
82
834. Review the PR as normal
84
855. Land when you're ready via the GitHub UI
86
87## Developer's Certificate of Origin 1.0
88
89By making a contribution to this project, I certify that:
90
91* (a) The contribution was created in whole or in part by me and I
92have the right to submit it under the open source license indicated
93in the file; or
94* (b) The contribution is based upon previous work that, to the best
95of my knowledge, is covered under an appropriate open source license
96and I have the right under that license to submit that work with
97modifications, whether created in whole or in part by me, under the
98same open source license (unless I am permitted to submit under a
99different license), as indicated in the file; or
100* (c) The contribution was provided directly to me by some other
101person who certified (a), (b) or (c) and I have not modified it.
102
103
104## Code of Conduct
105
106This Code of Conduct is adapted from [Rust's wonderful
107CoC](http://www.rust-lang.org/conduct.html).
108
109* We are committed to providing a friendly, safe and welcoming
110environment for all, regardless of gender, sexual orientation,
111disability, ethnicity, religion, or similar personal characteristic.
112* Please avoid using overtly sexual nicknames or other nicknames that
113might detract from a friendly, safe and welcoming environment for
114all.
115* Please be kind and courteous. There's no need to be mean or rude.
116* Respect that people have differences of opinion and that every
117design or implementation choice carries a trade-off and numerous
118costs. There is seldom a right answer.
119* Please keep unstructured critique to a minimum. If you have solid
120ideas you want to experiment with, make a fork and see how it works.
121* We will exclude you from interaction if you insult, demean or harass
122anyone. That is not welcome behaviour. We interpret the term
123"harassment" as including the definition in the [Citizen Code of
124Conduct](http://citizencodeofconduct.org/); if you have any lack of
125clarity about what might be included in that concept, please read
126their definition. In particular, we don't tolerate behavior that
127excludes people in socially marginalized groups.
128* Private harassment is also unacceptable. No matter who you are, if
129you feel you have been or are being harassed or made uncomfortable
130by a community member, please contact one of the channel ops or any
131of the TC members immediately with a capture (log, photo, email) of
132the harassment if possible. Whether you're a regular contributor or
133a newcomer, we care about making this community a safe place for you
134and we've got your back.
135* Likewise any spamming, trolling, flaming, baiting or other
136attention-stealing behaviour is not welcome.
137* Avoid the use of personal pronouns in code comments or
138documentation. There is no need to address persons when explaining
139code (e.g. "When the developer")