Ever since I announced my open source project Blazorade Bootstrap back in November 2019, I’ve been encouraging others to join. It can get a bit lonely in the open source world at times, and company can help with the motivation. It’s also a good way to get a second opinion on things. That’s why I’m happy to inform that we’ve now doubled the number of developers working on the project. What that actually means is, that in addition to myself, there is now someone else working on the project too. Doubling the amount of developers sounds better though, don’t you agree? 😉

The First Community Contributor

A couple of weeks back I got an e-mail from a guy called Evan Weeks. He had forked the Blazorade Bootstrap repository on GitHub, and had been playing around with the code base a bit. He had also implemented a few features that he thought were missing, and asked if I wanted a pull request. Well, of course! That’s what I’ve been looking for from the beginning! We exchanged a few comments on his pull request and changed a few things here and there. All in all, it was not long before I got to merge the first external pull request into the master branch.

After the first pull request, we’ve been working together with Evan towards the v1.0 release. We even added the ProgressBar component to the release. I had not planned to include that in the first release, just because of limited development resources. But Evan had it already implemented, so why not include it. Check it out on the Showroom App.

Basic Collaboration on GitHub

Now that there are more than one developer on the project, I’ve had to start thinking a bit differently about the development work. Everything can’t be in my head anymore, so it’s time to start leveraging the collaboration tools on GitHub. The chapters below describe the basic tools that we’ve started using when co-developing Blazorade Bootstrap.


The wiki is great for documentation, but for more actionable stuff, the Swiss army knife in GitHub is issues. Perhaps the choice of word is not the best in my opinion. Issue has, at least to me, a negative ring to it. In Azure DevOps they picked a better name for this, I think: Work Item. It’s an item that describes work that you need to do in order to get things moving in the right direction.

But, on GitHub, issues it is. There are also project boards, that allow you to organize issues and cards etc. on Kanban boards for a more visual experience. I really like the Kanban boards in Azure DevOps. They are very similar to project boards on GitHub in many ways. So I guess at some point, we’ll add in a little bit of project boards into the mix. For now though, I think we’ll stick with just issues and try to master them first before expanding our tool-set.

Pull Requests

Issues are good for describing things that you need to do to your code. Pull request (PR) are used to merge code changes from various sources into one branch, usually the master branch. The source can either be another branch in the same repository, or a branch in another repository.

Sure, I’ve been using PRs before, also when working on a project just by myself. If not for anything else, a PR groups a number of commits into one unit. In GitHub, you can then link this PR with the issue describing the change that the commits in the PR address.

But PRs from another repository is something that I haven’t tried before. On GitHub, anyone can fork a repository, i.e. make a copy of a repository in order to make changes to the code. Turns out that a PR from another repository is no different from a PR from another branch within the same repository.

What’s in a PR?

A PR has lots of nice features that I did not try before. In addition to regular comments, you can comment on selected files. You can also select one or more lines of code to target the comment at. You can add change suggestions that the author can simply click to accept, and they will be incorporated into the code without any further effort. Here’s an example of the first PR from Evan. We worked on it for quite a bit, as I described earlier in this article.

If you don’t understand the purpose of a pull request, don’t accept it. And definitely do not merge it into your master branch! Take time to understand the pull request, because once you accept it, you take the responsibility of maintaining it.

It starts with a very nice description on what the PR includes, and why the suggested changes are made. As the main responsible developer for a project, it is my responsibility to understand every change that the author of the PR suggests to the code. A good description helps a lot to understand the changes made to the files included, such as these. When I, as the primary responsible developer, accept the PR and merge it into master, I also take responsibility for that code, so it is imperative to get a good understanding of what’s included.


After the initial PR from Evan, there has been other contributors to the project too. A PR from another developer and a few issues reported by developers apparently trying out Blazorade Bootstrap in their applications. One of these issues was a bug that I was able to fix quite easily.

I know that my little Blazorade Bootstrap project is a drop in the ocean. Especially if you compare it for instance to the ASP.NET Core repository. Still, I cannot help feeling a little bit excited that complete strangers spend their time contributing to the project. I really appreciate the contributions very much, so thank you! Looking forward to continuing developing Blazorade Bootstrap into something useful for many developers!


Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *