How I Contributed to Open-Source While Learning Svelte

If you're looking to start contributing to open-source projects, or you want to make more open-source contributions, you might already be looking at different open-source projects, seeing where you can help out.

Sometimes, contributing to open-source projects comes naturally. You might even find opportunities to improve a project's documentation while reading, or in my case while learning Svelte.

In this article, I'll share how I ended up contributing to Svelte while learning through their interactive tutorials.

My background: deciding to learn Svelte

Before we continue, let me share my background.

Throughout my career, I've mostly done backend development. I wanted to learn frontend development to build my personal website.

I was deciding between React and Svelte. After browsing through multiple blogs (including this one) and Reddit threads comparing both, I was ready to choose.

Based on my quick research, React is ideal for complex and large-scale applications while Svelte is more beginner-friendly since I don't have to learn JSX and virtual DOM.

As someone who is new to frontends and just wants to build a personal website, I ended up choosing Svelte for its simplicity.

Learning Svelte through the interactive tutorials

Now that I've chosen to learn Svelte for building my website, the first I did was visit Svelte's website. Then I went to Svelte's interactive tutorial.

The tutorial is composed of four parts, covering both Svelte and SvelteKit, which is a UI framework for Svelte.

💡 Note: Here's my notes on GitHub while learning Svelte and SvelteKit.

Finding possible improvements in the tutorial

I went through the tutorials during my free time. The first part was pretty straightforward.

Once I got to the second part, in the slots section, I noticed a difference between the docs on the left, and the code on the right.

In the left part, the docs show <div class="card ">, while the code snippet on the right shows <div class="card">. The difference is that there's an extra whitespace on the class value.

Here's a side-by-side comparison to see the difference more clearly:

• <div class="card "> (Left part: docs)
• <div class="card"> (Right part: code snippet)

I usually notice small details like this, so I paused and looked to improve the tutorial page.

Improving the tutorial documentation

Websites and documentation that are open-source usually have an edit page button so readers can edit the page when they find issues or possible improvements.

Fortunately, the maintainers at Svelte also make it easy to edit the interactive tutorial pages.

While still on the slots tutorial page, I clicked the Edit this page link at the bottom.

Clicking the Edit this page button brought me to the GitHub repository of Svelte's interactive tutorial.

Reviewing the contributing guidelines

While reviewing Svelte's repository, I didn't see any CONTRIBUTING.md or any other open-source contributing guidelines, which can also be found in the repository's README.md.

What I did instead was review the previous commit messages to see if there was a specific commit format that I should follow.

There was no standard commit format, so I went with the conventional commits format.

Forks, commits, and pull requests through the GitHub website

Now, I'll show you the steps on how I contributed my changes through the GitHub website.

💡 Note: The screenshots I will show for forking, comitting, and creating a pull request on GitHub were made only to show the process.

I won't create an actual pull request adding a random white space. 😉

1. While still on the slots page README.md file, I clicked the edit button to edit the file directly on GitHub.
   

2. Since it was my first time contributing to Svelte's tutorial, I was prompted to fork the repository.
   

3. Once I forked the repository, I edited the file with the improvements. Then I clicked Commit changes.
   

4. I was prompted to enter my commit message, along with the optional description and commit email. Then I clicked Propose changes.
   

5. After making a commit, GitHub will automatically create a new branch with patch-<number> for the branch name. My branch name is patch-3. Then I reviewed the changes before clicking Create pull request.
   

6. Finally, I was prompted to enter a pull request title and description. Then I clicked Create pull request.
   

Making changes on the GitHub website works for small commits, but I'd still recommend cloning the project to your local machine to test your changes.

It's ideal to make a habit of testing your changes before making a pull request to open-source projects.

So that's exactly what I did. I cloned the project and followed the README.md docs for setting up the project locally.

Once I've tested out that my changes didn't break anything, I made the pull request.

Pull request merged!

After creating my pull request, it's up to the maintainers if and when they'll approve and merge it.

After a few days, one of my pull requests was merged.

Making pull requests that introduce small changes and have good descriptions increases your chances of having your pull request approved.

It also makes it easier for the open-source project maintainers to review your pull request, since they are usually busy with a lot of things.

Other possible improvements I've found and some tips

I'd like to share that I made three pull requests, but only one has been approved and merged as of writing this.

Here are the other pull requests if you're curious:

• docs: add code snippet for removing if blocks
• docs: update code snippet for consistency with source file

Based on my observations, the less visited pages of a website usually have more areas for improvement. In the case of Svelte's interactive tutorials, not everyone will finish the tutorials.

As a result, the less visited tutorial content might have more areas for improvement, since fewer people can spot potential issues.

So if you're looking to improve websites and documentation, you can start looking at the least visited pages first. 😉

Conclusion

To recap, I've shared my story on how I made an open-source contribution while learning frontend development with Svelte.

Hopefully, my story shows that sometimes, you can contribute to open-source even if it's not your first intention. You just have to follow one of the scouts' principles which is to "leave the campground cleaner than you found it".

When you see issues in documentation, you can improve it as long as it's open-source. Even if it's not open-source, you can still contact the project's support team or message the author directly.

Thank you for reading and I would love to hear your open-source experiences. Feel free to comment or message me here.

Good luck on your open-source journey!

Resources

• Svelte
• SvelteKit
• Learn Svelte and SvelteKit: Interactive Tutorial
• Svelte vs React
• learn.svelte.dev GitHub repository
• Conventional Commits
• Merged pull request to learn.svelte.dev GitHub repository
• Pull request: "docs: add code snippet for removing if blocks"
• Pull request: "docs: update code snippet for consistency with source file"