Ihar Hrachyshka is a seasoned OpenStack Neutron contributor. He joined the community back in Havana (2013) and is proud to be part of Red Hat OpenStack Networking team.
In the OpenStack community, we often emphasize that reviews are very important and that the best way to get up to speed with the community and to understand how it operates, as well as to get things done, is to join the hordes of reviewers for the project of your interest.
Indeed, reviews from newcomers are of enormous importance: doing reviews gives you a broader picture of what happens beyond the small thing that is most dear to your heart; it naturally aligns team members along parallel efforts, it’s a good learning experience both for authors as well as reviewers themselves and of course it helps to catch bugs before buggy code merges.
Last but not least, good reviewers are eventually promoted to core reviewers and it’s hard to know if you are good at something without trying it, so it makes sense that core reviewers are expected to prove their review record before getting access to +Workflow button. And so, we emphasize the need for everyone to take part in reviews, but we don’t tell people how to do it right.
Of course, people make mistakes, and that’s OK. Core reviewers are no different. More so, falling into the whirlpool of day-to-day reviews sometimes blurs the whole picture of why we do them in the first place (to merge code), with reviewers contesting around how many -1s they can put on others’ patches, however tiny the spotted mistake is. Nit picking and yak-shaving traditions in OpenStack community are well known and can frustrate and alienate some contributors, especially newcomers.
And so I posted a thread of tweets to remind people that we share our love for OpenStack with the idea that reviews are not the end goal, but quality and modern code shipped on time is.
#OpenStack reviews: it’s ok to +1 on first iteration. It doesn’t show how bad a reviewer you are.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: your +1 is as important as -1. Or +2. (Sometimes your silence is too, but in a wrong way.)
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: Your goal is to help merging good code, not showing how smart you are. Everyone already knows it.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: If you want to -1 for a typo in a comment or a commit message, just don’t. Pretty please. Thanks.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: think about all the load we incur on compute donors. Is your -1 worth respinning 20+ Nova instances? Climate change huh?
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: If you still want to -1 for a typo in a comment or a commit message, -1/-W, edit, push, +1.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: If you know how to fix the last standing issue, and it’s not controversial, just do it. Spare words.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: be grateful to people who respin your patches. They probably want to help you.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: If you respin a patch that already has a +2, just +2/+W right away. Save time. Don’t be a hostage of formalities.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: don’t expect patch to fix all wrongdoings. If a patch does one thing right, merge. Interested parties may follow up.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: You want something more to happen? Post a new patch, don’t ask your fellow to do it for you.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: Sometimes it’s better to merge a patch that is not 100% ready. Especially comparing to not merging anything.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: Sometimes you gotta trust your fellow and merge the code without fully understanding each line. That’s ok.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: Is it a backport? Don’t suggest that nice code optimization of yours. Instead post it to master. YOURSELF.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: Your project’ gate is broken? Bump all affected patches from gate queue, free others from your project misery.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
#OpenStack reviews: And for the most part, forget Stackalytics. Spare stats for your company’s PR dept.
— Ihar Hrachyshka (@ihrachyshka) March 23, 2017
Superuser is always interested in community content- get in touch at editorATopenstack.org
- Tips for surviving the OpenStack review process - April 5, 2017