HacktoberRest

As a wrap up of my first go round with Hacktoberfest, I want to share a bit about my final contribution of the month as well as some take aways from the experience.

One of the most interesting projects I came across this month was NeoGPT. It's a GPT based application that is being built to converse with documents and videos. While still in its infancy, the project has outlined a cool roadmap and has a very active base of contributors continuously expanding on its functionality. The project appeals to my desire to learn how to work with AI and neural networks. It is also at a development stage that it is not outside of the reach of my comprehension. Icing on the cake being it's Py based, which is my sharpest tool at the moment. I see it as a decent project to stay tapped into and grow my skills as the application develops.

The work associated with contributing to NeoGPT was a great progression from some of the first tasks I took on this month. Throughout Hacktober, I was able to contribute a minor change to a very big project (NodeJS), contribute some more substantial working code to a couple of small JS based apps and finally make a larger, more noteworthy contribution to a medium sized, but very active project. All of which provided

Having identified a few issues that felt within reach to tackle, I requested and was approved to contribute a logging function to be written as part of the program's database builder. While the issue was straightforward, there was a great deal of upfront investment in building the environment to run locally. This introduced me to an in-depth exploration of various frameworks and toolkits, including Anaconda, PyTorch, NVIDIA CUDA, just to name a few. In all honestly, it was daunting at times. I was back and forth on how and where to setup the environment, toggling between the Windows and Linux setup options. In the end, the functionality of the various project dependencies and add-ons was much more conducive to the Linux environment, which was learned the hard way at times, through significant trial and error. Additionally, this project relies on building local database as part of its engine, and is storage intensive as a result. Almost immediately I began reevaluating my hardware needs as I set my sights on more demanding projects in the future.

The setup curve just to be able to contribute as well as the greater contribution process, reinforced some of the observations I’ve been making through exploration of open-source development over the last couple of months. Some of those being:

• The importance of being able to find and research well-suited projects before getting too involved.
• The value of the community behind a given project and how the level of activity can really make a difference in how much you get from your involvement.
• There are several factors that need to be cosidered when looking at a potential project for the first time. An "easy" issue may prove difficult than expected, depending on the project and its contributor community.
• On a personal level, I have gained insight into some technical requirements of efficiently contributing to open source. For instance, I am really gravitating towards a robust and organized Linux environment as my prefered workspace. My experience has been that many dependencies and procedures related to building projects from source, just seem to be more functional and stable in the Linux OS.

Additionally, some of the main take aways I have from my Hacktoberfest experience are:

• The Hacktoberfest label doesn’t necessarily make finding worthwhile projects any easier. If anything, I felt that it was overrepresented by projects created strictly for the fest that didn’t really offer the experience to work on tangible products with long-term potential.
• “Good First Issue” was a great entry point into some manageable projects, although also heavily saturated with very small projects. I got the impression some people were just looking for help on their schoolwork.
• Whether the project is actively posting new issues and merging PRs is an important factor, as is the variety and progression in the types of issues being posted (open and closed).
• On steadily growing or larger scale projects, one should try to jump on issues that fit within their general skill set right away. Opportunities to contribute to relevant and interesting projects at your perfect level of difficulty aren’t guaranteed. Seizing the opportunities that do arise can be a great entry point to much more substantial contribution in the future.
• Timing is crucial when seeking contribution opportunities. To find great issues you need to engage in the search process regularly and move with some expedience when you find a decent prospect. There are many eager contributors out there, hungry to tackle the juiciest issues.

So just to wrap up my diatribe, this final project contribution was an experiential peak for me in terms of the type of project and how I was able to contribute. While disheartened at times by challenges faced in the environment setup and code examination process, the investment had a payoff as I was able to tackle a challenging and rewarding contribution.

The initial logging issue that I set out to address was hijacked by another PR (despite my being assigned the issue by the owner). That just reinforced the need to act swiftly and maintain strong communications.

Nonetheless, I was able to move onto a new issue that cheallenged me to explore how to use shell scripts to simplify the very setup process that had challenged me over the previous days. I was able to develop a bash script that streamlines the local application build for fellow users and contributors. While I'm increasingly confident with CLI and bash shell specifically, I had yet to delve into the potential of how to automate and streamline processes using scripts. Tackling this opened a lot of avenues of interest for me and really helped grow my confidence.

As project contributors were also actively making updates, the process proved a great test in how to use GitHub to effectively manage my changes while keeping up with the project as it developed. Another bit of positive reinforcement came as I was able to indentify and rectify a small but impactful error introduced as other changes were merged. As the error immediately impacted the current issue I was addressing, I was able to spot it in real time and offer a quick fix via a [separate PR]( (https://github.com/neokd/NeoGPT/pull/86) which was quickly accepted by the owner, who expressed appreciation for the catch.

In the end the process helped me develop a good report with the project owner and led to a direct request to expand on my shell script PR. I accepted this request to add support for Python virtual environment. While I haven't yet been able to tackle it, I am excited by the invitarion to contribute further. This looks like a fun project that I can work on for my upcoming Open-Source Release 0.3 project, and beyond.