Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: import posts from Dev #314

Merged
merged 16 commits into from
Jun 3, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
---
title: "Writing Your First Pull Request: Tips, Best Practices, and AI-Powered Tools for Success"
tags: []
authors: BekahHW
slug: writing-your-first-pull-request-tips-best-practices-and-ai-powered-tools-for-success
description: "If you're new to contributing to open-source projects, submitting your first pull request can be intimidating. But don't worry, we've got you covered! Check out these tips for successfully submitting your first pull request and making a great first impression as a contributor. "
image: https://media.dev.to/cdn-cgi/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F4xtz1foaoswl7f55hzgk.png
---

I don’t remember writing my first Pull Request (PR), and to be honest, I actually looked to see if I could find it for this post, but I know that I was really nervous because I wasn’t sure if I was doing it “right.” I think I actually spent more time worrying about it than I did actually writing the thing. The good news is that there isn’t really a right way to write a PR, but there are some best practices that can guide your writing and help the maintainer to be able to understand the changes.

<!-- truncate -->

## Review the Contribution Guidelines
Maintainers want to help you write your PR; that’s why they often outline contributing directions in their repositories.

![Jerry McGuire “Help me, help you gif”](https://media.giphy.com/media/uRb2p09vY8lEs/giphy.gif)

This file—often called CONTRIBUTING.md—gives guidelines for submitting your PR, including information like whether or not you need to write tests, the communication process, coding style, and how to submit your pull request. Check out [OpenSauced’s Contributing Guide](https://docs.opensauced.pizza/contributing/introduction-to-contributing/), as an example.

## Tips for Your First PR
Although every repository may have unique guidelines, there are general guidelines for all PRs. Here are some tips to keep in mind:

### Create a Clear Title
The title should give an indication of the issue, the changes made, and the type of PR–is this a bug fix, content or documentation change, new feature, or something else?

![OpenSauced title examples](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yv10emgx8a7grxyovbew.png)
BekahHW marked this conversation as resolved.
Show resolved Hide resolved
<small> OpenSauced’s CONTRIBUTING guidelines for titles</small>


### Give a Detailed Description
PRs often include a summary of the changes, as well as any relevant context or background information that might be helpful in understanding the proposed changes.

### Provide context
A well-written description will help the maintainer understand the purpose of the PR, the changes you’ve made, and why the changes were made. Here are some of the reasons the description is key to the success of the PR:

1. Facilitates collaboration. More details allow team members to share their feedback, identify potential issues, and ask questions. With open and transparent communication, a sense of community and trust among team members develops, leading to better collaboration.

2. Saves time. With a detailed description, the reviewer is more likely to quickly understand the changes made and avoid spending unnecessary time deciphering code. As a result, the developer will receive quicker feedback and avoid unnecessary rework.

3. Helps with future reference. A well-documented PR provides a historical record of the changes made. This helps future team members to understand the evolution of the code and the decisions made along the way. It also helps with future maintenance and debugging.

![OpenSauced's Examples for communication style](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sc4v1pihnggpq0asu671.png)
<small> OpenSauced’s [CONTRIBUTING guidelines for communication style](https://docs.opensauced.pizza/contributing/introduction-to-contributing/) </small>

### Link the issue
If the PR is related to an issue, you can link that issue and automatically close the issue when the PR is merged. One way to do this is to use this syntax: `closes #issue-number` for example, `closes #11`.

### Acknowledge Requirements
If there are requirements for new code to be merged in, like writing tests or documentation, you should also include that information in the PR. Other steps might include running current tests before submitting, agreeing to the Code of Conduct, and checking to make sure there’s not an open issue or another PR addressing the same problem you’ve fixed.

### Add a Gif!
If you want to know why, check out my last post, [How to Create a Good Pull Request Template (and Why You Should Add Gifs)](https://dev.to/opensauced/how-to-create-a-good-pull-request-template-and-why-you-should-add-gifs-4i0l)

## Bonus Level: Power Up Your PRs with AI

If you want to take your PRs to the next level, sign up for [GitHub’s Copilot for Pull Requests](https://githubnext.com/projects/copilot-for-pull-requests) waitlist! Copilot for PRs can give a summary of the changes, a detailed list with code references, or even create a poem 🤯

## Community Shoutout
For a great example from one of our community members, @nickytonline, check out [this PR](https://insights.opensauced.pizza/feed/99).

![gif of Nick Taylor’s PR](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i19g7u3uwqzjf3exvbal.gif)

If you’re looking for an open source project to submit your first PR to, find a project that’s well documented, aligns with your interests and skills, and is accepting PRs from new contributors. Check out [OpenSauced’s Hot Repositories](https://hot.opensauced.pizza/) or [Insights](https://insights.opensauced.pizza) to find popular repositories and explore based on your favorite topics. And if you want to see your PR mentioned by OpenSauced, be sure to add it to your [highlights](https://insights.opensauced.pizza/feed)!

Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
title: How Vercel is Using GitHub Discussions to Build a Strong Next.js Community
tags: []
authors: BekahHW
slug: how-vercel-is-using-github-discussions-to-build-a-strong-nextjs-community
description: "Learn how Next.js, a flexible React framework, is leveraging GitHub discussions to strengthen its community, promote job opportunities, and showcase companies using Next.js."
---

Communication is key to maintaining a healthy open source project. It’s even more important if one of your projects has more than 100,000 stars. Using a tool like GitHub discussions provides an opportunity for communication for more than bug reports, show and tell, or product announcements. It can provide a path to support and connect the community, and that’s exactly how Vercel is using discussions on their [Next.js repository](https://github.com/vercel/next.js/discussions).

<!-- truncate -->

## What is Next.js?
> Next.js is a flexible React framework that gives you building blocks to create fast web applications.

Vercel, the company behind Next.js, provides a platform for deploying and hosting Next.js applications, as well as a range of other tools and services for building and scaling web applications.

## How does Next.js use their discussions?
At first glance, the list of discussion features for Next.js looks pretty ordinary, well except maybe the squirrel with the hat as the icon for the Show and Tell section. Next.js takes it a step further and leverages GitHub discussions to provide its community with a space for participation and interaction. The project prioritizes community building by pinning important discussions at the top of the page: Companies/Sites using Next.js, Who’s hiring (April 2023), Who wants to be hired (April 2023).

### Companies/Sites using Next.js
This discussion lists companies that are using Next.js, allows folks to respond to the post with their site that’s built with Next.js, and also links to their [showcase](https://nextjs.org/showcase) as well. So if you have a Next.js site, and you’re not already showing it off, add it to [this discussion](https://github.com/vercel/next.js/discussions/10640)!

### Who’s hiring
This monthly post provides a space for companies to advertise job openings for individuals with Next.js experience, and for job seekers to find opportunities. I checked out their posts all the way back to November 2021, and loved seeing how many included this line: “At least one company has hired someone as a result of it!”

[https://twitter.com/nutlope/status/1610667757565083648?s=20](https://twitter.com/nutlope/status/1610667757565083648?s=20)


### Who wants to be hired

This pinned post is for job seekers with Next.js experience to showcase their skills and experience. Companies looking to hire can browse the post for potential candidates. This gives a nice glimpse into the Next.js community and provides support for job seekers and does my favorite thing: offers to send swag to anyone who was hired through the post.

![Screenshot of Who wants to be hired (April 2023) post](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ug608pczuotc58ag8i6f.png)

It’s great to see Next.js building a strong and supportive community through discussions. If you’re a Next.js developer looking for work and you have contributions you’d like to highlight, you can add them to your [OpenSauced highlights](https://insights.opensauced.pizza/feed) and link them to your post.


<small>header image created using [midjourney](https://www.midjourney.com/app/jobs/53c570b9-3cc2-48c5-9fe0-8d855cfbeb34/).</small>
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
---
title: Managing Community Health Files and Templates with a .github Repository
tags: [github]
authors: BekahHW
slug: managing-community-health-files-and-templates-with-a-github-repository
description: "I collect open source projects like some people collect discord servers. To be accurate, I have 525."
---

I collect open source projects like some people collect discord servers. To be accurate, I have 525 repositories. Now, before you yell at me, many of those are from my bootcamp lessons when I was learning to code. But I’ve been known to start and stop projects more than once. What I _have_ learned through that experience is the importance of consistency. If you’re in an organization that has multiple repositories, you might find yourself adding the same files over and over–files like the CODE_OF_CONDUCT.md, Pull Request (PR) and Issue templates, and CONTRIBUTING.md. As developers, adding these files repeatedly starts to feel like we’re violating [DRY code principles](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Fortunately, the .github repository can help solve this problem.

<!-- truncate -->

## What is a `.github` Repo?
A `.github` repository is a special type of repository in GitHub that allows maintainers to store community health files and templates for their projects.

> Community Health files promote the well-being of the community and focus on communication, documentation, supporting members through a code of conduct, and community recognition.

The `.github` repository–found at `https://github.com/<username/organization>/.github`- can house the community health files for your organization as the default files. According to [GitHub](https://github.blog/changelog/2019-02-21-organization-wide-community-health-files/), “While the file itself won’t appear in the file browser or Git history for each repository, it will be surfaced throughout developers’ workflows, such as when opening a new issue or when viewing the Community Profile, just as if it were committed to the repository directly.”


![Screenshot of the open-sauced/.github repo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i41566ytubxwkz60kjh7.png)

Using a `.github` repository, allows maintainers to efficiently manage the files and templates that are important for their project's workflow and community and ensure consistency throughout the organization's repositories. So what do you add to the `.github` repository? One example is a Pull Request Template since they’re often standard across repos.

## How to Add a PR Template

Adding a PR template to your `.github`repository is straightforward. First, navigate to the repository in question and click on the "Create new file" button. Next, in the file name field, type `.github/PULL_REQUEST_TEMPLATE.md`.

In the main text field, you can add the content of your PR template. This can include prompts for information such as the purpose of the PR, the changes made, any potential issues or concerns, and any additional context or resources that may be helpful–check out ours [here](https://github.com/open-sauced/.github/blob/main/.github/PULL_REQUEST_TEMPLATE.md). You can also use markdown to format the template, making it more readable and easier to understand.

Once you have added your PR template, click the "Commit new file" button to save it to your repository. Now, every time a contributor opens a new PR, they will be prompted to use the template you created.

## Considerations for Maintainers

When creating a PR template, keep in mind that the template is easy to read and understand. Remember, the template is supposed to make things easier for you and the contributors. What information do you need to be able to review the PR more efficiently? What information can guide a new contributor through writing a PR for the first time?

Finally, the beauty of using one template for all your repositories is that if you decide to update it, you only need to do that in one location. As your project evolves and new requirements emerge, you may find that the template needs to be revised or you might feedback from contributors and other maintainers, and make changes as needed to ensure that the PR template remains effective and useful. If you're interested in more content on PRs, check out [Writing Your First Pull Request: Tips, Best Practices, and AI-Powered Tools for Success](https://dev.to/opensauced/writing-your-first-pull-request-tips-best-practices-and-ai-powered-tools-for-success-3bg9) and [How to Create a Good Pull Request Template (and Why You Should Add Gifs)](https://dev.to/opensauced/how-to-create-a-good-pull-request-template-and-why-you-should-add-gifs-4i0l).
Loading
Loading