This is what can happen if you don't use Git's cherry-pick command properly in open source projects. Similarly to hand-picking the finest cherries and putting them in a basket, this command allows you to move individual commits from one branch into another.

It great for when you're collaborating with someone else on an open source project because it saves you the trouble of having to merge entire branches.

Now as powerful and awesome as the Git cherry-pick command is, it can create duplicate commits, making it difficult for open source maintainers to update their project's codebase or solve bugs.

Scared? Fear not, my fellow open source contributor. I have some strategies that you can use to prevent duplicates when cherry-picking commits.

Strategy 1: Use the --no commit Option

This option is one of the most common methods to prevent duplicate commits. It copies the changes from a branch but it won’t create a new commit, which can be very helpful if you’re working on a contribution with another person. Let’s see it in action.

Step 1: Pick your Cherry (commit)

After you pick the open source project you and your partner are working on, go to their fork and click on the Commits tab.

Screenshot of a Pull Request's tab. The Commits section is highlighted with a orange oval

From there, pick the commit that you want to put on your Pull Request by clicking on its SHA number.

Screenshot of commit history. The SHA number is shown on the right, highlighted in a green oval.

As you can see in the image, the SHA number is a unique id that contains the following information about a commit:

• The type of changes made
• When the changes were made
• The contributor who made the changes

After that, paste your chosen commit's SHA number in the following command:

git cherry-pick --no-commit <commit SHA number>

Step 2: Check for Spots and Plant

After running the --no-commit command, now it's time to inspect your picked commit. You can do this by doing the following commands:

• git diff : This command shows you all the lines added, deleted, or modified by the cherry-picked commit. Here’s how it would look if someone was making a translation contribution:

git diff 2f410g1
diff --git a/01-intro.md b/01-intro.md
index 1234567890123456789012345678901234567890..0000000000000000000000000000000000000000
--- a/01-intro.md
+++ b/01-intro.md
@@ -1,3 +1,4 @@
- Hello, everyone!
+ Bonjour, tout moun!
- Welcome to our course!
+ [Placeholder for French intro]
+ Bonjour, amis!

• git show commit SHA : With this version of the git show command, you'll see the name of the contributor, date of their commit, their email, and the list of changes they have made. If we were to take the SHA number from the previous example and used this command, here's how the output would look:

git show 2f410g1 (Frenchify intro and materials!)
Author: John (johnseed@example.com)
Date:   2023-12-18 18:07:15 -0500

Bonjour, le monde!  Time to add French translations to our intro and course materials.

* **01-intro.md:** Warm welcome and placeholder for the French translation.
* **materials.md:** Module descriptions replaced with [placeholders] for French versions.

... and other exciting French changes in 4 more files!

Now that you've picked your method of inspection, go to your files to make the changes and create a commit message as shown below.

git commit -m <"message">

From there, push the changes into your Pull Request's branch.

Now, —no—commit is not the only strategy you can use to prevent duplicate commits. Let’s look another one.

Strategy 2: Make Some Changes With --edit

If you know the edits that you want to make in the commit you picked, then the --edit command is for you. Here it is in action:

git cherry-pick -e 2f450g1
diff --git a/docs/content/pets.md b/docs/content/pets.md
index abcdef12..34567890 100644
--- a/docs/content/pets.md
+++ a/docs/content/pets.md
@@ -1,4 +1,5 @@
 # Pets

 This is a file about pets.
+New content added about pets.

 ## Different types of pets
# Continue cherry picking process
git cherry-pick --continue
# Change commit message
git commit -m "feat: add section"

As shown in the code snippet, we initiated an interactive cherry-pick of a commit containing changes to the pets.md file. During the cherry-picking process, you may make direct edits to the file, including adding new content and changing the heading. From there, we created a new commit message and pushed the changes to our branch.

Start Picking

There it is folks – strategies to help you avoid duplicate commits when cherry-picking.

Using this command effectively not only makes it easier for you to work on collaborative contributions, but also keeps your commit history clean.

If you want to learn more about cherry-picking commits and want to put those skills to use, check out this guide by Atlassian and this course by OpenSauced. Also, check out BioDrop to view my other technical content and connect with me.

Credits

Image of commit history from How to fix the order of commits in GitHub Pull Requests by Andrew Lock

Your commit history plays a huge role in the future of the open source projects that you contribute to, and commit messages are key to making this possible.

What are commit messages, you may ask? These brief explanations describe the changes you made to the codebase, and they're very useful if things like bugs occur.

Commit messages are also great checkpoints if you’re getting back to an open source project that you have not contributed to for a while and need to remember the changes you’ve made so far.

Feeling intimidated? No worries. In this quick guide, you’ll learn how to write effective commit messages.

What Makes a Bad Commit Message?

Like most things in life, we have to learn about what makes an unhelpful commit message before we learn how to write a good one.

Let's look at one example:

mention information

Even though this commit message describes the change, it does not explain why the change was made, which can leave maintainers feeling confused.

It also does not state what kind of information was mentioned. Maintainers might be wondering "Was is it a missing code snippet? A link to a specific section?". These are things that you want to avoid when writing commit messages.

Now that we’ve seen the bad, let’s learn how to turn this commit message into something that maintainers can understand.

Characteristics of a Good Commit Message

Remember how I said the earlier commit message was a bit vague? Well, here’s how we can fix it:

Step 1 – Mention the type

This is where you specify the kind of change you’re making to the codebase. This makes it easier for maintainers and other contributors to gain a better understanding of your contribution.

Here’s how this step would look with the sample commit:

feat: mention information

Since the sample commit seems to focus on adding some text, I decided to go with feat because it often is used to describe contributions where information or a new feature is added to an open source project.

Here are some other common abbreviations that are used to categorize commits:

• docs: This is commonly used to describe revisions to current versions of or updates to an open source project's documentation.
• fix: This is typically used for fixing bugs in the project's codebase or small grammar errors in the project's documentation.
• chore: This is often used for a contribution that make take longer that usual to finish.

Step 2 – Summarize the change

This is where you give an overview of the change and how you did it. This helps maintainers understand how your contribution solves the problem you’re trying to solve.

Now it’s important to note that GitHub has a 72-character limit so you'll need to keep your description within that range. Let's look back at our example:

feat: mention information

Remember how I said that it does not specify the typo that was fixed? Well after doing some thinking, I decided to write this:

feat: mentioning Christine Peterson in the course's intro

That's so much better! :) Unlike before, this version of the sample commit mentions the kind of information and specifies where it was added in the project. This helps maintainers gain a better understanding of why this contribution was made.

Optional Step – Add a description

This is where you describe the change in more detail by mentioning why you made it. While this step is optional, consider doing this so that maintainers can get an idea of how your contribution enhances or solves an issue in their project.

Here’s how it would look with our sample:

I decided to add this information so participants get accurate information.

When doing the description, I decided to keep the describe short yet specific. That way, it would help maintainers understand why I made this contribution and how it enhances the project.

Now let's put these parts altogether:

feat: mentioning Christine Peterson in the course's intro

I decided to add this information so participants can get accurate information

Now in comparison to the original example, this commit message is more effective because it does the following:

• Specify the type commit being made
• Describes how the contribution enhances the project
• Summarizes the change

Looks great right? 😉

Wrapping Up

Whether you’re a new contributor or a seasoned veteran, writing commit messages effectively is crucial to communicating your contributions to maintainers.

If you’re looking for more ways to step up your commit message writing skills, check out Conventional Commits. Also, follow me on BioDrop to check out my socials and other technical articles.

Ooh, I know the feeling. When I first joined the open source community, I was so overwhelmed with the plethora of projects out there, as well as the expertise that all the other contributors seemed to have.

It felt like I was a small fish taking its first swim in the big ocean. But eventually, those feelings went away after discovering this:

The "Good first issue" label. I'd like to call this the guiding light of GitHub repos

Remember how Peter Pan told Wendy that the second star to the right will take her to Neverland? Well, this guide will show you how to harness the power of the good first issues label so you can end up in digital Neverland.

Fly kiddies fly!

What is a Good First Issue?

Before you go to GitHub and plow through open source repositories for good first issues, let’s define what it is.

A good first issue is a label that GitHub-hosted open source projects use. It describes issues that are reserved for people who are new to open source in general or those who are new to a particular project.

Think of this label as the bat signal James Gordon often uses to let Batman know that help is needed in certain parts of Gotham City.

The bat signal

Now, knowing what good first issue labels are is one thing, but finding them is another story.

How to Find Good First Issues on GitHub

If you already know the project that you want to contribute to, you can do the following:

First, click on the Issues tab:

Screenshot showing the issues tab in GitHub's interface

Then click on the Label filter:

Screenshot showing the label filter displaying various labels

Now you can pick the good first issue label:

Screenshot showing the "good first issue" label

And there you go! Anything that the project has labeled "good first issue" will come up.

What if you don't have a project in mind?

If you’re not sure which repo you want to contribute to, there’s also awesome curated lists of open source projects that have raised good first issues on GitHub.

You can access it by going to the navigation bar and clicking on Explore:

Click on "explore" in the left navigation menu on GitHub

Then type “good first issues” in the search bar:

Searching for "good first issues"

Go to the Filter By section and click on Topics:

Filter by "Topics"

Now before you go and hunt for good first issues, there’s just one more piece of advice that I want to share with you.

How to Decide What Issues to Work on

As cliché as this sounds, sometimes the simplest thing is actually the hardest. There are some issues that have the good first issue label that are actually pretty difficult to solve once you've started working on them.

I remember when I first contributed to the MDN Web Docs, I had to add the <section> tag to certain parts of the docs. On the surface, it seemed pretty easy, but then I found that it took me a while to find the files that needed those tags.

To avoid making the mistake I made, consider asking yourself the following questions before you pick a good first issue:

1. Does this issue truly suit your interest(s)?
2. Do you have the skills to solve the problem?
3. Has it been assigned to someone else already?

By asking yourself these questions, you’ll be able to find a truly good first issue for you.

Conclusion

There you have it folks! Your guide to finding good first issues. 😊 Starting your open source journey can be very exciting and intimidating. But by searching for good first issues and critically analyzing them, you should have a great experience.

Now, go forth and fly! 😊

Credits

• Good first issue label image by GitHub
• Peter Pan GIF by Disney
• Tim Burton Film GIF by Tech Noir

#

Like most newbies, I went to Google to find some inspiration. As I scrolled through the internet, I stumbled upon Skillcrush’s list of HTML and CSS projects for beginners.

Number 5 piqued my interest, so I googled some images on how HTML forms should look. I thought “Oh I can do this. This looks easy!” But this project turned out to be a bit harder than I thought.

In this article, I will show you three things I have learned in surviving, I mean making HTML forms error-free. Let’s get started! 😀

Tip #1: Make Sure the Labels and Inputs Match.

When I first started creating HTML forms, I would often use the following methods for creating email input fields:

<label id="text"> Your Email</label>
<input type="text" id="text" name="text">

I would often use text as the label and id's attribute because I thought it was the correct method.

This all changed when I started using WAVE’s accessibility checker to learn how to make my code more accessible. When I ran my form through the checker, it pointed out that the email input did not have a properly associated label, and that can cause screen readers to have difficulty presenting it to users with disabilities.

So, I googled a few sources and found ”HTML Inputs and Labels: A Love Story” by Amber Wilson. Through reading this article, I learned that it’s best to use specific names in the id attribute.

With a new feeling of confidence, I started using this approach. Here’s an example:

In the code snippet above, I used email as the label and input’s id attribute. When I ran it through the accessibility checker, there were no red Xs.

While this victory was sweet, I wanted to learn more ways to ensure that labels and inputs were accessible. So I went to Google and found this HTML Forms attributes article. Through reading, I learned that you can add other attributes like placeholder, which demonstrates how the user should present their contact information.

Through these experiences, I realized that creating harmonious labels and inputs for a form is like constructing a sandwich. You want to make sure that your flavors work well together and use the best features of your oven (or whatever appliance you use) to make your sandwich nice and toasty.

Now before we start getting hungry, let’s move on to my next tip. :)

Tip #2: Be More Semantic When Creating a Button

Formatting your form’s buttons is crucial to the efficiency of your HTML form. Buttons are the main way that your user’s information is sent to your desired destination.

When I first started creating HTML forms, I used to create buttons like this:

<input type="submit">

Like the labels and inputs, I would get a red x on WAVE’s accessibility checker. In the results, it mentioned that a value attribute was missing, which makes it difficult for the screen reader to detect the button.

With that in mind, I decided to do what most beginners do when creating this feature:

<button> Submit</button>

When I ran the code in the WAVE accessibility checker again, it passed a few tests. But something inside me told me that my previous solution was ok too and that I just needed to find a way to add a value attribute to it.

With a new thirst for knowledge, I went to Google and found this article on how to create accessible form components. In the section about buttons, they recommend using the following methods to make this element semantic:

<input type="Submit" value="Submit">
<button type="Submit">Submit</button>

When I ran the first snippet into the accessibility checker, I received no red Xs. The same result occurred when I ran the second code snippet through the accessibility checker.

At first, I didn't know which one to pick because both approaches made the form accessible. But something inside me told to go with what I truly wanted. So, I took a deep breath and chose the following code line:

I decided to go with the second code snippet because it's more explicitly labeled, which makes it easier for screen readers to scan. It's also easier to remember, and is the method that I often use for creating buttons.

Think of it as deciding to go with the brand of bread you’ve always used for your sandwiches instead of picking a different one. As cliché as this saying sounds, sometimes simplicity is best.

Before you start getting hungry again, there is just one more suggestion for making your HTML forms error-free.

Tip #3: Pick the Best CSS Framework Based on Your Needs

When I first started creating the style for my forms, I used to force myself to use CSS frameworks like Flexbox. At the time, my feelings of imposter syndrome were at an all-time high due to seeing other people creating great forms with those frameworks. I felt that if I started using them too, I would get those same designs.

At first, I was happy with using Flexbox as it made things like centering content easier as shown in the snippet below:

Unfortunately, I still wasn't satisfied in the end. I found that the design did not come to fruition as I envisioned.

To combat this feeling, I went to Google to find something to help me solve my dilemma. When I was about to give up, I stumbled upon the article, “How to style forms with CSS: A beginner’s guide” by Supun Kavinda.

My heart leaped with joy when it pointed out that you can use vanilla CSS to create beautiful designs. For example, to make the texts’ input fields look more presentable, I could do this:

input[type=text]{
padding: 10px;
}

With newfound confidence, I gave vanilla CSS another chance, and I can honestly say I was so happy with this decision. Here’s the final result:

I wanted to keep my design simple, so I used basic elements like text-align property to center my form's content.

If I had to pick something that exemplifies this experience, it would be like a sandwich cut into two triangle slices. Simple yet effective.

Overall, sometimes, it’s best to go back to the basics before moving on to something more challenging.

Conclusion

There it is folks, my three tips on how to make your HTML forms error-free.

I know creating HTML forms can be frightening in the beginning. But with these tips, confidence, and some imagination, you can HTML forms that wow your viewers. Now go forth and be great! :)

I know, I know, you’ve probably heard “Contribute to open source!” countless times in Discord groups and tech-related social media posts. But trust me, it really can be a great way to gain experience as a technical writer.

For one, you get to work on projects that are often displayed publicly. This can be a great way to showcase your skills to your professional network.

Also, contrary to popular belief, code is not the only way you can contribute to open source projects. You can use your writing skills to help maintainers improve their projects' documentation.

And contributing to open source exposes you to new technical languages and software, which the Bureau of Labor Statistics describes as one of the many important skills in tech writers.

Still not convinced? No worries – in this guide, I will discuss how you can find open source projects that need tech writers. I'll also describe what tech writing-related contributions to these projects might look like, and suggest how to display them publicly.

How to Identify Open Source Projects That Need Technical Writing Contributions

Many open source projects need help with their documentation. Picking a project to make docs-based contributions to will be based heavily on your interests, the level of writing skills you have, and the opportunities available.

When it comes to finding open source projects that need contributions, I highly recommend asking your colleagues about the projects they are involved in. Working with friends + open source? It's two for the price one! :) Once you've picked your project, my next tip is to do the following:

1. Go to the Issues tab on the project's repository.

Yellow Arrow pointing to Issues tab

2. Click on the Label section

Orange arrow pointing at the Label section

3. Type "documentation" in the textbox and voilà!

"documentation" appearing in the textbox

Now if you are looking for something more specific, here is my list of open source projects with a focus on documentation:

The Good Docs Project

If you’re looking to start gaining experience in working with documentation, I highly recommend joining this group. :) They have diverse working groups that focus on different types of writing whether it’s creating documentation templates that other developers can use in their own open source projects, improving the content on the organization's website, and doing QA (Quality Assurance) for the templates that community members have created.

Codecademy

If you’re knowledgeable about a particular programming language and want to share that knowledge with the world, then I highly recommend contributing to Codecademy's docs and article repositories. They provide templates based on different needs such as providing a new entry for a certain chapter and updating/editing an existing entry.

Astro

If you’re an avid user of Astro, then you can share your tips on using this software on their docs repo. Their documentation team is very open to working with members with different levels of experience.

Now picking a project is just one step. Let's look at some different ways you can contribute to open source projects as a technical writer.

Ways to Contribute to Open Source as a Technical Writer

Congrats! You've picked your project. Now, you just have to decide how you will use your tech writing skills to contribute.

I know this part can be difficult but don’t fret – now we're going to discuss some different types of contributions you can make.

Revise typos and other grammar errors on the README file

This file is crucial to the foundation of an open source project. It's where they describe the project’s purpose and the steps to contribute to it, so it should be as clearly written as possible.

If you're reading through the README file and you see a comma missing or an unclear sentence, raise an issue about it to maintainers and make those edits (if they approve, of course).

I made this contribution to EddieHub when I first joined their community. It was not only a great way to introduce myself, but it also taught me how to tailor documentation to a specific audience. Now this not the only text-based contribution, let's look at another one! :)

Create an internal docs style guide

This entails creating a guide that defines the standards for writing and formatting the documentation for an open source project. It helps instruct contributors on how to effectively write for open source.

In this document, you'll see information such as how punctuation marks should and should not be written, specific ways to format code blocks, and the tone and voice that contributors should use when writing about the product.

A great example of this would be the Contractions section in Google's Developer Documentation style.

Also, I decided to make a doc style guide for EddieHub's Linkfree project after watching a video by Portia from Document Write's YouTube channel. She talked about how open source contributors, especially those who want to pursue tech writing as a career, can benefit from having these sorts of style guides.

Through creating this guide, I've learned the following:

1. Writing in a new style or language: Since Linkfree's main demographic is in the U.K., the maintainers wanted the guide to be written in British English. I've never used this version of English before, so it was interesting to learn how words are spelled, capitalized, and what punctuation marks are used.
2. Using new tech tools or frameworks: MDX (Markdown X) is the technical language contributors use to maintain Linkfree's documentation. Simply put, it's Markdown that allows to you to put JSX (syntax that let's you put HTML code in JavaScript). I've briefly worked with Markdown, so it was a bit easier to implement this language in creating the docs guide.

Now, a style guide is only one of the many docs-based contributions you can do for an open source project. Let's look at another one! :)

Add to a tutorial for a product

If you're good at teaching or find yourself reading an open source software's tutorial that is missing key information, consider doing this as your contribution.

A great example of this would be the tutorial section on Audacity's website. It's a free open source audio recording and editing software.

As a person who's newer to the open source community, I noticed that most beginner-level content never really provided tips or advice on how contributors can implement their open source contribution experiences when looking for jobs or during interviews. So I was scrolling through OpenSauced's repository on GitHub and noticed that this kind of content would be helpful in their free "Intro to Open Source" course.

I presented my idea to Bekah, the company's User Experience Lead, created a pull request, and violà, it got merged!

I highly recommend making this kind of contribution because a great way to gain practice is by simplifying technical content for a global audience of all skill levels. It also develops your detail-oriented skills.

Now, before you go, there’s just one more thing to consider when gaining tech writing experience through contributing to open source projects.

Show Your Work

When it comes to the importance of displaying your creations, Austin Kielon said it best: “Show your work”.

I mean, we’re writers for crying out loud! It’s in our DNA to display content through words, so why not do it with our own stuff?

You can write about your projects via your blog, social media posts, or record a podcast episode about it.

If you’re looking for something more structured, I recommend using OpenSauced's free Chrome extension. It’s a tool that allows you to keep track of the GitHub open source repositories you currently contribute to and those you plan to contribute to.

They also have this feature called “Highlights” where you can pick certain contributions to post to your profile and share on LinkedIn and Twitter. To learn how, check out their tutorial.

This would be a great thing to reference during your job interviews and it can be an inspiration for other open source contributors. When I showcased the docs style guide I created for Linkfree on Twitter, one of my colleagues liked it so much that she thought it'd be good to have one for her project. So per her request, I created one! :) Never underestimate the power of displaying your work.

There you have it folks, your guide to gaining writing experience through contributing to open source projects. I know it can be intimidating to do – especially at first – but with these tips and a positive attitude, I know you’ll succeed.

Credits

Open Source Symbol from UXwing

Tech Writing Icon by Ylivdesign from Dreamstime

Well that's kind of like HTML. This markup language is like the wood to your coding project. If it’s invalid, your solution will collapse.

Now don’t fret. In this article, I'll give you some tips to help you make sure that your HTML is error-free as you build your coding solution.

You heard Dwight. Let's do this! :)

Common Causes of Invalid HTML Syntax

Before you go and start investigating for unclean code like Sherlock Holmes (the Benedict Cumberbatch version to be exact 😉), let’s briefly meet some examples of syntax that can ruin your HTML file:

1. Improper nesting of HTML elements

"HUH?" indeed

2. Deprecated HTML tags

Interesting choice 😏

3. Missing tags

Oh closing tag, where are you?

Now that you've met the culprits, let’s figure out how to catch them before they mess up your HTML file and destroy your coding project.

Sir yes sir!

Improper Nesting of HTML Elements

To briefly review, nesting occurs when an HTML element is inside another HTML element.

<p>Coded by <a class="profile-link" href="<https://github.com/CBID2>" target="_blank"><em>Christine Belzie</em></a></p>

Now a nested element becomes evil – I mean improperly nested – when you place an HTML element inside the wrong area of the other element, like this:

<a class="profile-link" href="<https://github.com/CBID2>" target="_blank"><em>Christine Belzie<p>Coded by </p></em></a>

The code above would be considered invalid because the

tag is not related to the tag and the

tag is not related to tag. As a result, you get an unorganized paragraph.

To replace the improperly nested element, I highly recommend doing what I like to call the Sandwich Model. It entails stacking the head and closing tags of styling HTML elements within the primary tags, kind of like how you stack up all your toppings and fillings between two slices of your favorite bread.

<bread> <topping> </topping> <filling> </filling> </bread>

Now if you think improperly nested tags were evil, wait until you see the next villain.

Muahaha! 😈

Deprecated HTML Tags

Simply put, deprecated HTML tags are basically when you use HTML elements that the tech industry has decided should no longer be used. Here's an example:

<center>
  <figcaption id="img-caption">Rihanna performs on stage in San Siro Stadium for Anti World Tour 2016. </figcaption>
</center>

In the code snippet above, I used the

But it’s considered invalid since it is no longer used, which can cause your project to not function in the best way possible.

It’s like wearing like wearing platform shoes from the 70s when everyone else is wearing Yeezy’s, Sketchers, or Converse.

To quote Pauly D from "Jersey Shore", "What are those?!"

The best way to fix deprecated HTML tags is to refer to websites, blogs, and other sources to stay updated on the latest versions of the code. Let’s give the snippet I mentioned a makeover:

<figcaption id="img-caption">Rihanna performs on stage in San Siro Stadium for Anti World Tour 2016. </figcaption>

figcaption{
    max-width:100%;
      height: auto;
    display:flex;
    justify-content: center;
     font-family: 'Montserrat', sans-serif;

  }

To center the

See how pretty the snippet looks now? When your code looks good, your project operates well, too. To stay updated on HTML, MDN, in my opinion, is a great source because they always let the readers know when certain tags are out of date.

Now hold on, we’re not out of the woods yet, there’s still one more invalid syntax that we have to meet.

Don't be scared...yet! 😈

Missing Closing Tags

You know how you use to scoff and roll your eyes whenever your writing instructor took points from your essay for having a few misspelled words or a missing period? Well, they were on to something – because the same idea applies to your HTML file.

A common issue you might run into is missing closing tags. Let's see what that looks like.

<div class="user-info">
<h3 id="user-name">Victor Crest<span class="age">26</span></h3>

If one of your code lines is like the code snippet above, your HTML file will break, causing your project to not look so great like in the output below:

Think of it like a missing tire in your car (or whatever vehicle you use to transport yourself). Without it, you would be driving like this:

Hang in there buddy!

To fix this error, I highly recommend using the sandwich method that I mentioned before.

<div class="user-info">
<h3 id="user-name">Victor Crest<span class="age">26</span></h3>
</div>

As you can see in the code above, we've added our closing <div> tag, causing the snippet to now look like this:

See how improved the code looks now? Remember, think of a line of code like a sandwich. When one slice of bread (or in this case, a closing tag) is missing, your masterpiece falls apart, leaving you angry, sad, and sometimes hungry.

So sorry penguin!

Wrapping Up

There you have it! Three common types of invalid syntax to look out for in your HTML file.

Remember, this file is the foundation of your coding projects, so Happy HTML file = Happy project! 😊

Glad to know that we agree with each other.

Credits

• Ben Mckenzie Fox GIF by Gotham
• Can't Touch This High Heels GIF by BrownSugarApp
• Closing Tag image from "How to Easily Find Missing Closing Tags in HTML (with Coda 2)" article on Clicks Nathan
• Dwight Office Tv GIF by The Office
• Driving Michael Richards GIF by Seinfield GIFs
• Fox Tv Fire GIF by Bob's Burgers
• Oh Yeah Yes GIF by Mauro Gatti
• Ren And Stimpy Reaction GIF by Giphy
• Sad Nft GIF by Pudgy Penguins
• Screenshot of Google from the "Why does Google use the deprecated HTML tag still?"discussion forum on Reddit
• Screenshot of improper nested tag from "How is the DOM Affected by Improperly Nested HTML Elements?" article by Louis Lazrus on Impressive Webs

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