# Making Better Pull Requests

DevFeed: [Making Better Pull Requests](<https://devfeed.tech/articles/making-better-pull-requests-38437.md>)

Original publisher: [Read original article](<https://eevis.codes/blog/2021-10-18/making-better-pull-requests/>)

Author: Eevis Panula

Published: 2023-01-03T08:57:47.653000Z

Content type: tutorial

Language: en

Sources: [Eevis Blog](<https://devfeed.tech/sources/eevis-blog.md>)

Topics: [pull-requests](<https://devfeed.tech/topics/pull-requests.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Maintainers](<https://devfeed.tech/topics/maintainers.md>)

Tags: [best-practices](<https://devfeed.tech/tags/best-practices.md>), [context](<https://devfeed.tech/tags/context.md>), [contribution](<https://devfeed.tech/tags/contribution.md>), [discussion](<https://devfeed.tech/tags/discussion.md>), [maintainers](<https://devfeed.tech/tags/maintainers.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>), [review](<https://devfeed.tech/tags/review.md>), [scope](<https://devfeed.tech/tags/scope.md>)

## AI overview

A tutorial on improving pull requests for open-source projects. It recommends keeping changes in scope, giving reviewers context, including pictures of changes, and using pull requests for discussion while checking each project's contribution guidelines and templates.

## Source excerpt

Hactoberfest is here! Time to find those issues and participating repositories, write some code, and create pull requests! I've been eagerly waiting for October, mostly because of Hacktoberfest. Last year, I participated in Hacktoberfest by being a contributor and a maintainer. If you're interested, you can read about my blog post about last year's experiences: Eevis Panula - Story of an accidental open source maintainer This year, I decided to take it a bit easier. I mean, as mentioned in the blog post, last year we bought a house and were moving during October. Another challenging thing from last year was the maintainer part. I loved it, but it really, really stressed me out. So I'm not going to do it this year. And there's another piece to the puzzle this year as well: I'm switching jobs, so that's another reason to take it easy during this Hacktoberfest. One big part of Hacktoberfest is creating pull requests. I remember the first time I made a PR in an open-source repository. I didn't know the repository's maintainers, and it didn't have any guidelines for pull requests, such as a pull request template. I had no idea what the maintainer expected from a PR. I felt super anxious. If I had known back then what I know now, it would've been easier for me. So that's why in this blog post, I'm sharing some tips on how to make better PRs. These are the best practices I've picked up along the way. However, note that there might be some other conventions in the project you're contributing. Be sure to check them. There might be a pull request template or contribution guidelines. The tips I'm going to give are the following: Keep the pull request in scope Give context to the reviewer Add a picture of the changes Pull request is a place for discussion Keep the Pull Request in Scope One reason for keeping the PR in scope is that smaller PRs are always easier to review than those with lots of changes. Sometimes, of course, the feature you are working on is a big one, and thus