Hacktoberfest Week 1

For Topics in Open Source Development, the other students in this course and I are partaking in Hacktoberfest - a month-long open source community event where participants submit 4 pull requests to participating projects.

In this post I will cover my experience finding a good issue to work with and submitting my first pull request.

Searching for issues

The first challenge was to find issues that were acceptable to work with. I queried for issues on GitHub with the following filters:

is:open is:issue label:hacktoberfest label:"good first issue" archived:false no:assignee -linked:pr comments:0 created:>2023-01-01 

This will filter down issues that are:

• Participating in Hacktoberfest
• Open and unassigned
• Created recently
• Marked by the maintainer to be easier to work with

Browsing through various repos, I learned to avoid repos that:

• Were inactive/abandoned
• Had few to no comments
• Were simple student projects
• I simply did not understand

I avoided issues that:

• Involved adding onto lists of content
• Involved localization (I only know English)
• Were about providing wireframes/design prototypes
  • I presumed that designing (vs. actual coding) was outside the scope of this class
• Were about creating their readme
  • This signaled to me that the project was unorganized and unmaintained if they relied on external contributors to document their project
• Involved refactoring the entire project
  • Out of scope

Process

My original plan to contribute was:

1. Find available issues that are labelled hacktoberfest
2. Check that I can properly set up the project locally
3. Respond to the issue and:
   • Introduce myself to the maintainer
   • Briefly described my propose solution and approach
   • Request assignment & permission before starting

Blockers

Within these parameters, I found there was no shortage of interesting projects to worth with. The difficulty came however with certain blockers.

My first blocker was being unable to successfully run certain projects despite following their set up guide. After following the extensive set up guide for a repo, the program would act in an aberrant way that prevented future development i.e. receiving random errors. It would be unclear without further context whether this was an issue during set up, runtime, or if the project was simply broken.

The second blocker were projects with inaccessible pre-requisites. Many projects I've looked into required signing up for an external proprietary service that I was unable to set up.

For example, a project required that I specifically created a developer account in the development platform Deta Space. According to the documentation, this was done by enabling an Enable Developer Mode switch on the sign up page which was not present. Unfortunately, I later realized that the documentation was obsolete and there was an undocumented developer-specific sign-up route https://deta.space/signup?dev_mode=true. Now that I know, I may revisit this project. It's just a shame that the requisite platforms for certain projects may be blockers in and of themselves.

Another blocker was waiting on feedback for proposed improvements prior to starting. Certain issues like this one with this accessibility-focused USWDS React component library have multiple approaches. In this case, the maintainer wondered whether or not a label should be hardcoded into a combo box React component for the sake of enforcing accessibility and that they could be convinced of either approach. I posted my response detailing my approach to this problem. Unfortunately, I did not receive a response. I am not sure whether I should have submitted a pull request anyway, but I would prefer to have some initial feedback before starting one.

Finding the first issue

I found a project called movex - a serverless data sharing infrastructure that allows one to easily develop network-focused apps without worrying about the back end logic. This looked like a great tool to use especially for front-end developers who want to focus on client-facing functionality and aesthetics.

The set up process was straightforward. The project was very well documented, between its contributing guide to its API documentation. The only new requisite I had to prepare was NX to handle building and testing the project.

The issue was simple - to add commitizen to the list of project dependencies. This project uses commitizen to enforce a structure to commits, similar to the Conventional Commits specification which I already know. Up until now, the project relied on contributors to install commitizen globally on their machine (i.e. npm install -g commitizen) before they made commits. This way, everyone was using commitizen from the start.

Submitting my first pull request

After reading through the contribution guidelines and pushing my changes, I noticed that in my pull request I forgot to properly sign my commits - whoops! The fix was easy thankfully - I set up a new gpg key, associated it to my GitHub profile, amended my commit retroactively (making sure to sign it this time), and force pushed it to my feature branch on my fork. The maintainer was fast to respond and pleasant to interact with - certainly a project I look forward to following and potentially to work on further.

Takeaways

The biggest lesson I learned from submitting my first Hacktoberfest pull request and talking with my colleagues was that instead of always waiting for permission from maintainers to publish a pull request, sometimes I should put one out anyway. A pull request can be a great starting point for discussion under some circumstances. The same can't be said for larger, more involved issues that absolutely do require further communication and coordination. The experience of submitting this first issue, while simple, helped me learn the intricacies of contribution, particularly with signed commits.

Another lesson I learned was that it truly is a wild west of projects out there. Aside from the time pressure of racing to contribute to Hacktoberfest-specific issues before they're assigned to someone else, there is a spectrum of quality with these projects. They may feature incomprehensible errors out of the gate, lack proper documentation, are cumbersome to set up, etc. There are also many well-maintained projects out there as well, it just takes some time (and luck) to sift through and find them.

Thanks for reading!