-
Notifications
You must be signed in to change notification settings - Fork 61
feat: import posts from Dev #314
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
Merged
Merged
Changes from all commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
8b3b8bf
Add authors yml
BekahHW 2188f33
Add authors yml
BekahHW b4a662c
Add first post
BekahHW ec61dda
Fix path to community resources blog
BekahHW 3804312
Add a bunch of dev blog posts
BekahHW 4c6ff32
Remove the colon from the title to prevent error
BekahHW a9a8da8
Fix formatting errors
BekahHW 0826b98
Add allllll the blog posts I have on dev for OpenSauced
BekahHW 053d33c
Add allllll the blog posts I have on dev for OpenSauced
BekahHW 979d17c
Revise the slug to fix error
BekahHW 0f9cc08
Fix broken links
BekahHW f779f0c
Add truncate to a bunch of posts
BekahHW 7f7c809
Add truncate
BekahHW 4351b78
Create folders for each year and separate posts to make it more manag…
BekahHW 2a32bb2
Fix docs link
BekahHW cf7b83d
Remove md emoji syntax and replace with list and words
BekahHW File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
65 changes: 65 additions & 0 deletions
65
...your-first-pull-request-tips-best-practices-and-ai-powered-tools-for-success.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 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. | ||
|
|
||
|  | ||
|
|
||
| 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? | ||
|
|
||
|  | ||
| <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. | ||
|
|
||
|  | ||
| <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). | ||
|
|
||
|  | ||
|
|
||
| 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)! | ||
|
|
||
39 changes: 39 additions & 0 deletions
39
...20-how-vercel-is-using-github-discussions-to-build-a-strong-nextjs-community.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 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. | ||
|
|
||
|  | ||
|
|
||
| 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> |
37 changes: 37 additions & 0 deletions
37
...04-24-managing-community-health-files-and-templates-with-a-github-repository.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 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.” | ||
|
|
||
|
|
||
|  | ||
|
|
||
| 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). |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.