No worries, I’ve been there myself when I started getting more comfortable in the open source world. So, grab a chair, your favorite snack or beverage (I highly recommend water. It’s fresh and good for you! 😉), and your notebook (or in this case, your laptop). Because I’m about to share five techniques that will have you reviewing pull requests like a boss.

Neil deGrasse Tyson says "Let's Do This!" to give you confidence!

Feedback Technique 1: The “Show and Tell” Review

For this technique, you provide screenshots or links to other sources that help explain the benefit of the new approach that you’re suggesting to your fellow contributor. Here's how it's done:

First, take a screenshot of the thing you want to convey in your feedback. I highly recommend using Fireshot. It's an easy way to take screenshots on your computer.

This is a GIF of someone taking a screenshot of an image via a Mac

Then, go to the repository of your choosing and click on Pull Requests

A yellow circle surrounds the third tab called "Pull Requests". Click there to pick the PR you want to review.

Once you pick the pull request you want to review, click on Files Changed:

Add your comments, then drag and drop your image in the textbox.

In a textbox,

Click Submit review and volià you're done! 😊

There's a green button saying "Submit Review". Click on it after you finish your review.

In my experience, this type of review is helpful when giving feedback on pull requests that require adding a feature to an open source project's website (for example a logo) or an image on one of its Markdown files. It can help the person see how their contribution impacts the overall project.

It's like if you were watching a commercial for a facial soap and you see the scenes where they show close ups of how the product makes your skin healthier. Showing someone an image of what needs fixing can help convey what's going on more clearly.

Speaking of skin, here's another strategy where your shifting powers, I mean adaptability skills, can be helpful.

Feedback Technique 2: The “Chameleon” Review

The “Chameleon” is a feedback giving technique where you adapt your PR review based on the type of contribution that your peer is making. It's like how a chameleon changes their skin color to fit in with their surroundings (minus the hiding from predators part of course 😉).

For example, if you’re reviewing a pull request that's text-based like the one in the image below, I highly recommend giving feedback via dialogic questions (for example, how does this resource stand out from other courses that teach JavaScript?).

This technique is helpful because it encourages the recipient of your review to think deeply about their contribution. It also teaches you how to tailor your feedback based on the type of pull request that you are reviewing.

Now that you know the Chameleon, the next technique you'll learn is one that can help you swipe through fields, I mean, long lines of code.

Feedback Technique 3: Two Peas in a Pod

The “Two Peas in a pod” is a PR review technique where you comment on one line of code in the conversation while another contributor gives feedback on another line code in the same pull request.

Here's an example:

Two contributors comment on one line of code

My comment on a different line of code on the same pull request

As shown in the first picture, it's helpful to point out why certain methods won't work and discuss some alternatives the pull requester can use. Additionally, consider commenting on a different way to improve the PR once you picked the line of code you want to improve.

When using this method, I highly recommend encouraging you and your fellow reviewer to pick a line of code that suits your strengths because it'll make giving feedback easier.

Since my background is in writing and education, I decided to comment on the text-based line that you see in the second picture whereas the other contributors focused on improving the image element due to being more experienced in coding.

This method helps you develop your written communication skills and ultimately makes reviewing pull requests less stressful. That's two benefits for the price of one! 😊 Cool right? 😉

Speaking of lessening your stress, I have another strategy that will have you reviewing pull requests like the Flash from The Justice League!

Feedback Technique 4: Teach’em Review

This “Teach’em” review is a PR review technique where you pretty much instruct your peer on how to improve their PR instead of just pointing out the issues in the PR.

Here are some examples:

My suggestion: turning the <div> element into a more semantic HTML element.

I give tips to the contributor how to make their code-based contributions more accessible

When using this technique, I highly recommend pointing out an area of improvement. Then, you can briefly teach a strategy they could use in the future.

This approach can help improve your coding skills and develop your written communication skills, which is very useful in the world of tech.

Now, there’s just one more technique that will help you upgrade your PR reviewing skills.

Feedback Technique 5: The “Suggestion” Review

If you're focusing on other open source projects, have a deadline for an assignment, or you're just tired from a long day at work but want to review pull requests, this feedback giving technique will be the ultimate tool in your open sourcer kit. It focuses on giving constructive feedback through your review.

Here's how it's done:

1. Click on the Files Changed tab of a person’s pull request:

There are four tabs underneath a person's pull request. The final one "Files changed" is circled in yellow. That's the tab you pick in the first step

2. Hover over the line of code you want to review and click on the blue plus sign:

There is a blue plus sign over the line code that has a yellow covering. This indicates that you have picked a line of code you want to review.

3. Click on the file icon that has a plus on top and a minus sign on the bottom:

4. Rewrite the line of code, improving it as you think is necessary:

There's a yellow arrow point to an area that says ```suggestion. This where you rewrite the line of code that you choose to review.

5. Click on Add Single Comment

There is a yellow arrow pointing at the "Add single comment" button. This is what you click on to insert your suggestion into the person's line of code.

6. Write your comment in the textbox, click on Request Changes, and Submit Review.

The first arrow points to a textbox, the place where type your comment. The second arrow points the last radio button labeled "Request Changes". The final arrow points at a green button labeled "Submit review".

I highly recommend using this feedback technique for pull requests that are text-based because it will show your suggestion to the person who made the pull request, which is especially helpful if you are too tired or don't have time to give a brief grammar lesson (trust me, I've been there).

Like the other feedback techniques I previously mentioned, the suggestion review can also help you improve your detail-oriented skills as it encourages you to think of the best way to convey your feedback. It's pretty awesome! 😊

Conclusion

Congratulations, you now have five feedback giving techniques in your Open Sourcer toolkit!

Before I let you go, I want you to remember this. Open source contributions begin and end with you, so use your powers wisely. Now, go out there and be the best pull request reviewer in open source!

Deadpool and his crew is walking slowly towards their next challenge. Be like Deadpool with your pull request reviews! :)

Credits

Let's Do This GIF by National Geographic

Super Hero Walking GIF by 20th Century Fox Home Entertainment

Screenshot GIF from "How to Take a Screenshot on a MacBook" by Hung Nguyen

Would you use product X?

Do you like product X?

What do you enjoy most about the user experience?

These questions all elicit feedback. However, these questions are broad. If you want more specific feedback that you can transform into changes to your product, you will want to ask questions that elicit more details.

If this insight seems obvious, why do we - as builders, designers, and coders - all too often ask for product feedback that leaves us no better off than we were before asking?

I believe - and will provide examples to support in the article that follows - that by asking probing questions, we can collect actionable feedback that leads us to make worthwhile product improvements.

But only by asking the right questions, at the right time and in the right way, can this value be unlocked. If you need help learning to ask the right questions (and follow-up questions), this article is for you.

I have learned how to ask questions through a mixture of patience, practice, coaching, and building.

First, some relevant stories from my past missteps.

How my firsthand experiences building led me to ask different types of questions

When I started a FinTech company to help kids and parents learn about financial education at home, I asked parents if they thought financial education was important to the well being of their children.

What do you think these parents said? As a matter of fact, nearly 100% said that “yes” such education was important.

Guess how many of these parents went on to use the product I built? Only a fraction.

This short example illustrates the importance of asking the right questions. I asked the wrong one. Perhaps I should have asked the following:

• What tools do you use today to teach your children about financial education?
• Why do you value teaching your children about money?
• How are you planning to educate your children about money?

All three of these questions probe the same assumption as the first question: namely, that parents will want to teach their children about financial literacy.

But these questions are fundamentally better because they probe deeper and give the user room to explain their logic and rationale.

This qualitative feedback - where we can go deeper beyond assumptions and platitudes - is where insights exist to shape better product experiences. And that is a central goal for builders.

A second aim of builders is to not only build products that people use, but to build products that people find uniquely valuable.

When I was starting my career I had aspirations of being a Product Manager. A friend, who was a successful Senior Product Manager at Google, challenged me with a simple assignment: build a product that 10,000 people use.

I thought deeply about the challenge and looked into tools to help with student loans and Mapping APIs. Ultimately I decided that I would build a tool that helped solve various problems in my own life. I sat down and thought through these questions:

• What is a problem I currently have that technology can help address?
• Can I build a solution?
• Do I know how to build the technology?
• If I build a product, can others benefit from it too?

If you build it they may come...but you need to ask what your users want and need first.

I decided to build a Chrome extension that enabled users to quickly switch between tabs. After roughly 6 months on the Chrome store the free extension passed 10,000 active users.

I sat down with friends and started asking them how they used the tool and what they needed the tool to do to add more value in their lives.

I honed in by asking very specific questions:

• How many times do you use the tool (and I would cross reference this with internal data)?
• What does the tool not help you do that you need it to do?
• Can I join you at your workstation or desk and observe you using the tool?

These questions led to new insights.

Ultimately I decided that the improvements users wanted were beyond my technical capacity.

So I let the tool sustain itself without further coding improvements.

What did I learn from this experience?

Firstly, building is rewarding. Solving your own problems with small tools and hacks can be great fun and also educational.

Secondly, when you build something that has utility, and others start to use it, you have a unique opportunity to learn from users to make improvements.

These improvements, in turn, can yield even better product features, designs, and outcomes. These enhancements can better satisfy and align with the needs of your users.

Hence a small flywheel can be set in motion.

And lastly, it’s ok to build and push the limits without committing to further releases and development work. It’s ok to say “no” and allocate your time and technical resources elsewhere.

By asking the right questions you can unlock real value.

But this value does not need to be applied just to development cycles. It can also make you realize you are headed down a path you don’t want to be on.

And you can use insights from users - and gleaned from the questions that you ask - to make better informed decisions.

I had a product manager who once noted: “if the feedback is not a strong yes, then it's a no.” I think about this belief system a lot because I am always looking for perspectives that can help shape, inspire, and influence the products I design and build.

I would challenge that product manager - and you - to amend that quote: “If the feedback is not a strong yes, ask why not. If you can’t glean insights from users, then it’s a no.”

The art of intentional product feedback starts with you - the builder - and an open mind.

But tied closely to an open mindset is the ability to ask the right questions. It is healthy to say “in the spirit of open-mindedness, I’m striving to learn and I am learning by asking questions.”

There are many educational tools, online schools, engineering communities with online coding tests, and communities like freeCodeCamp to help you learn to engineer, design, wireframe, and deploy products.

But how many of these tools teach you how to ask questions, think critically about the replies, and then circle back with relevant follow up questions?

When building anything for others - a tool, a website, an app, or highly specialized software (like a QR Code Generator) - you need to know what people want, need, and most strongly value.

Only by asking questions can you learn these things. Only by asking questions can you produce a product that gets your users to a “strong yes.”

When it comes to discussing quality and how we can improve, the most common things that come to peoples minds are tests, processes, procedures, QA departments, and so on. But they leave out the most important, basic thing, the pre-requisite for achieving high quality: the right attitude. Quality is all about having the right attitude. That’s the starting point.

Sure, you need all the other things mentioned above — tests, processes, and procedures — to achieve and maintain a high quality standard. But if you and/or your people don’t have the right attitude, all of the aforementioned things can just become a bullet list on a presentation slide. People can go through the motions of running the relevant tests and following the prescribed processes, but without the right attitude it all becomes a farce of ticking off checkboxes. ?

Pursuing perfection

When it comes to the pursuit of perfection, I’ve always had the belief that:

That’s my mantra and I swear by it. So much so, that I even have it as part of my Twitter profile. ?

The first part simply means that no matter what you may think, nothing is ever really, truly perfect. If you think something is perfect, wait for five minutes, or two days, or two weeks, and you’ll start to see the small imperfections.

However, this does not mean that you should lose hope or become disheartened. Just because your thing (product, process, art, whatever) is not perfect doesn’t mean that it can’t be improved upon. This is where the second part comes in: by pursuing perfection you can move closer towards achieving perfection. And eventually, you’ll progress to such a state that you’ll surprise yourself by the progress made.

Psst. It still won’t be perfect, so what?

This line of thinking has grown out of my background as a computer engineer/scientist. With every passing day, I find many more examples that make me think that it is generally applicable. Unless you can disprove this mathematically, I am going to claim that my mantra is universally true. ?

This mantra is the basis for developing the right attitude, achieving high quality, and continuing to improve upon it. Never be satisfied with the quality you have, always be trying to improve.

To improve, be pessimistic

Strange as it may sound, I find this an invaluable attitude to have towards the quality of whatever it is that you are doing.

Assume that whatever you have made is not going to work, or that it is of low quality. Be pessimistic about the quality of your work.

Then — systematically — prove your pessimism wrong!

Yeah, that’s right (can’t help but picture David Puddy). ?

You may think of this as a roundabout way of doing things, but it works! It ensures that in working to overcome your pessimism (even if it’s a manufactured one) you’re actually improving/ensuring quality.

For a developer, this means writing tests to prove that the code actually works. For an author, this could take the form of soliciting feedback from an experienced editor. Tailor the prove-your-pessimism-wrong step to your particular situation, but do it.

All too often, I have seen (and occasionally been a victim of it myself) people suffering due to overconfidence in their work. “It’s just a one-line code change, not even going to create a ripple in the pond”!

Wrong! Unless you have regression-tested and proven that everything still works, assume that even your tiny change is going to wreak havoc on the larger system. Be pessimistic!

Feedback is golden

_Photo by [Unsplash](https://unsplash.com/@jasonrosewell?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Jason Rosewell on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

This may come as a surprise to many, but you get feedback from only 4% of dissatisfied customers! Putting it another way, for every customer that bothers to complain, 26 others are quietly unhappy and at high risk of leaving without giving you the chance to improve. As you can imagine, unless you listen very carefully to what little feedback you get and take heed, you run a very high risk of living in a fool’s paradise.

That’s why customer feedback is pure gold. I can’t stress enough that you’ve got to really listen to it!

Listen and internalize, even if it hurts

As a creator, it may hurt to listen to people criticize one of your creations. But think of it as invaluable feedback (we know how important that is ?). The feedback may come from a customer, or it may come from within your organization. Either way, it’s an opportunity to learn, improve, and grow.

Creators who take umbrage at feedback and become defensive and non-receptive will never be able to achieve the highest quality standards. These are the people who will either:

• start looking for excuses as to why the failure happened (with the basic theme being “It wasn’t me”), or
• become non-receptive and internally keep insisting there’s nothing to improve and that nothing could have been done any better.

These are the sorts of people who will not deliver good quality and will continue to fall further behind their peers in terms of expertise and skill.

The flip side of the coin

_Photo by [Unsplash](https://unsplash.com/@ryanthomasang?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Ryan Thomas Ang on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

On the other hand (you knew this was coming, right? ?), don’t let a single-minded focus on quality give you tunnel vision and make you blind to everything else.

Be Practical

One has to balance the need and desire for quality against other factors like cost and time.

As an example, let’s say your company already has an electrical switch that can take a million on/off operations without failing. You want to improve this switch so that it can handle 10 million operations. But the development, usage of newer and more expensive materials, and testing combined will take an additional two years, with the resultant switch costing 3x that of the million-operation switch. Considering all that, is that quality improvement still worth it?

In most cases, the answer would be a resounding “no”. Maybe your time will be better spent developing a version that is water-resistant, making it more suitable for outside use, and opening up your product to a whole new market.

Beware of the outliers

_Photo by [Unsplash](https://unsplash.com/@rupert_britton?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Rupert Britton on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

The “listen to your customer feedback” advice also comes with a caveat: “Beware of the outliers”. These are the people who will never be satisfied, will always be complaining, and will make you run around trying to satisfy their every whim. Such customers will increasingly start complaining about super-specific scenarios (things that affect a very small percentage of users) or about things that are very subjective (specific to personal taste).

If you try to satisfy these outliers, you might end up spending time on features (for example, adding “skins” to your software) that do not have universal appeal. In the process, you’ll take resources away from developing the product in directions that will give the greatest benefit to the greatest number of people.

In the end, this often comes down to a judgement call about when to de-prioritize a customer’s feedback. There’s no sure-shot formula to get it right every time.

Conclusion

Adjust your attitude to enable you to pursue perfection relentlessly, with eyes on practicality and ears receptive to feedback.

If you found this article helpful, please don’t forget to clap! ?

In keeping with with spirit of this article, constructive discussions and corrections are most welcome!

I have an open-source project. It has 17 users.

It actually has somehow scraped together a few hundred stars on GitHub, managing to be the most-starred repository for a few wildly popular tags like [relationships](https://github.com/topics/relationships), [human-readable](https://github.com/topics/human-readable), and [journaling](https://github.com/topics/journaling) (but, alas, not [journal](https://github.com/topics/journal)). You’re probably very impressed. You may be thinking something like, “What useless piece of code could possibly be at the intersection of those things?” or “GitHub has tags?”

But don’t be intimidated by my extraordinary success. Three years ago, all this was just a few lines of code and an idea. I wanted to see if I could visualize the ebbs and flows of my relationships with the people I care about.

I also wanted to have a program tell me who I haven’t talked to in a while, so I could be better at staying in touch. Okay, and I also wanted to store all of this information in a way that was easy to see, edit, and play with. I guess it was more than one idea after all.

That should have been the first clue that I didn’t have the clearest idea what I was doing. But I’m strong-willed and felt confident that I’d figure out the details later.

So I hacked together a program that I called [friends](https://github.com/JacobEvelyn/friends) (tagline: Spend time with the people you care about. Introvert-tested. Extrovert-approved.) and used it regularly for a year, at which point I assumed that its (minimal) featureset was complete. On a whim, I posted it to Hacker News, where it briefly made the front page for the first and only time in my life. (Side note: if you ever see a post on Hacker News in which a calm comment reads something like, Maintainer here. I'm glad to see this on the front page, and happy to answer any questions. don’t believe for a second that that person isn’t shaking with uncontrollable nervousness and excitement.)

And then an interesting thing happened. I got suggestions.

Lesson 1: Users have really good ideas

My friends and coworkers, bless them, will tell you I have no problem “sharing my opinion.” Translation: I usually think I’m right and can have a hard time accepting input from others. (Not cookies though, I accept those fine.)

I thought I knew about my own project. However, my pompousness disappeared pretty much immediately when I started reading users’ suggestions. To date, I’ve had 16 (!!!) GitHub issues opened by someone other than me. (Out of a total of 110. I need to get out more.) And almost every one of those has been a suggestion that I would never have thought of and that makes friends unequivocally better. In fact, counter-intuitively, these new features have been so spot-on that they’ve often led to much simpler code.

What has amazed me the most is how these users often seem to “get” the idea of friends better than I do.

I consider friends to only have 17 users despite all of its downloads and GitHub stars. This is because only 17 people have cared enough to share their feedback with me or offer to contribute a pull request. I don’t know if others are using it in perfect bliss or downloaded it once and then forgot about it. But 17 people have dedicated time and energy to show they care. I love every single one of them.

Lesson 2: Being nice pays off

From the beginning, I wanted to be a friendly, supportive, patient, mentoring maintainer. Not the gruff maintainer who says “this feature should not be added” with no further explanation.

So I added this friendly note to the top of the README:

NOTE: Participation is encouraged! Make issues, ask questions, submit pull requests (even if it’s your first time contributing to open-source — you’ll get lots of help), and give feedback!

I adopted the Contributor Covenant. I added friendly contribution instructions. I made sure friends followed all of GitHub’s best practices.

And I put in the time and effort to be friendly when responding to users. I knew that was the right decision when users started leaving comments like:

“Excellent. Thanks for your patience and suggestions. I’m pretty green with this stuff.”
— codyjroberts

“This my first pull request to an open source. I learn Many things from your Comments. Thank you So much for that.”
— sivakb

“Thanks for the explanation! … Also, I gotta say, your cheeriness is great! ?”
— greyhillman

Being nice doesn’t feel like work to me (though I get that it can for others) but either way, it pays off. It lets me have deeper conversations with my users. Discussing their suggestions often reveals other ideas they have but didn’t think to bring up. I even had a video call with a user halfway across the world!

Being nice also lets me ask users unsolicited questions, which at first I was afraid to do. Maybe they’d be annoyed that I’m bothering them? That fear was silly. People like sharing their opinions!

Lesson 3: Users can be anywhere

I’m not sure why I expected this (other than my apparent geocentrism) but I’d assumed my users would all live in my home country. Not even close! My 17 users don’t even all live in countries where my native language is particularly common. (And why should they?)

My 17 users live on four different continents.

That humbling fact boggles my mind.

Lesson 4: Making money is hard

I was spurred by success stories of open source projects being sustained by donors. So I recently put up a few donation badges onto the project README. I’d love to be able to spend more time with friends, and even a small amount of money is a clear signal that it’s worth my time.

So how many donations has GitHub’s most-starred [human-readable](https://github.com/topics/human-readable) project received? Exactly zero. (And honestly, I’m not sure how to change that.) It is, I admit, a little discouraging.

Still, if I was in it for the money I wouldn’t have spent so much time building, well, this. And donations are just one way to contribute. If you give me as much feedback, love, and help as my 17 users, you don’t need to give me a cent.