Don’t: Every contributor has a reason to be excited about creating a Pull Request (PR). It is fun, self-satisfactory and can be rewarding. However, new or even intermediate developers sometime create PRs in a way that is not recommended by the community. For example, you are going through documentation and notice a typo, broken link or poor grammar, etc. DO NOT create a PR right away as you hit such things and end up creating many PRs. Creating many PRs this way is strongly discouraged by the community, as it generates a lot of noise in the system and is often perceived as the person simply trying to increase their PR-count. And it is not just the Kubernetes community but any other big projects like OpenStack discourages this as well. Creating PRs this way also creates burden on test and build resources, so this is a big DON’T.
Do: Combine your observations and create just one PR (or couple if needed) addressing typos or broken links etc. This does not mean that if you can not find multiple typos or broken links or such other small doc changes than you do not create a PR at all. Any improvement to the project is good. However, by combining small improvements into one PR you are helping better usage of test and build resources and reviewers time. Also this is a desirable way of fixing such things. And know what? The community will respect you creating PR this way.
Don’t: Contradictory to above recommendation, do not create a single large PR when it involves lots of new code or existing code changes. Why? Because it will make reviewer’s life difficult when multiple ideas are merged into one. It is always tedious and can be error prone to review a PR with hundreds of lines of code (LOC) or when multiple issues or features are addressed in a single PR.
Do: Break down you code changes into more than one PR in such way that they can be build and reviewed independently. The reviewers will appreciate it very much.
Don’t: Do not create an issue for your question. While you are learning or playing with Kubernetes you may run into questions. Many issues reported on upstream repository are questions. This unnecessarily increases the total numbers of issues and creates load on the triage team. Also when you ask questions as an issue, chances are you may not get reply right away which will probably be counter productive to you.
Do: Ask on Stack Overflow, ServerFault Kubernetes page or on the Kubernetes Slack channels. Even better, before asking, do search for your question on those websites and chances are that you may find answer. If you do not find answer or an existing answer to a similar question does not satisfy your need, ask a question by all mean. With respect to the Kubernetes Slack channels, there are many channels for specific Special Interest Groups (SIGs) and interest. For example,
#sig-clietc. Ask question to the right channel and you most likely will get an answer quickly.
Don’t: Do not amend your commit and push with git after a reviewer has commented your PR. Depending on the open source project set up and convention, this can be a common practice in certain projects but it’s not recommended in the Kubernetes. Let’s say you created a PR and received a comment. You addressed a reviewer’s comments, amend your commit and push it. Guess what? The reviewer is required to start over to review changes.
Do: Create a new commit incorporating reviewer’s comments. This way you will end up with multiple commits but it helps reviewers review code faster than starting over and it is also a recommended way by the community. What happens when your changes are ready to merge but you have multiple commits? At that point you get a /lgtm comment and reviewer will ask you to squash your commits. Squash your commits now into one and push it to your PR. This may require you to force your push (i.e. use
git push –f) but it will create a single final commit into your PR which then be merged.
Don’t: If you have forked Kubernetes repo and are developing on top of it, or using the Kubernetes in any other way that’s just great. But if possible, do not just limit yourself using upstream code. If you do like to contribute but do not have time or skill to contribute code, that’s OK, — do not walk away from the project — as there are many other ways you can contribute.
Do: Contribute. It is common that you, or your company, may use the project for one or other reason. Sometime even just for learning. Sometimes you run into a bug or need for a new feature, and you write code to fix the bug or implement feature locally and continue using it. Sometimes you wish things were done differently. In all these cases, you should reach out to the community. If you have fixed a bug or implemented feature locally, do create a new PR or provide your feedback. That way you are making project better and becoming a good member of the community. There are many ways you can contribute and become well recognized member of the community. While contributions require some time commitment, code contribution is not the only way the community would like contributors. There are many equally important areas like test, triage, documentation, release, and project management to name few. Reach out to community via slack channels or mailing list and ask if there are specific areas that you can help with. Even better, reach out to a specific SIGs (for example, sig-testing or sig-cli).
And at last, if you have read the blog post all the way here, you sure deserve a bonus Do’s – do make friends in the community. It is good for you, for the community and for everyone.