DEV Community: Bryce Seefieldt

NeoGPT PR merge achieved

Bryce Seefieldt — Fri, 12 Jan 2024 12:58:29 +0000

I have worked my way through the scope of contributions I set out to make with the NeoGPT open source project. It has been a positive experience and went a great deal smoother than some past contribution work. This is primarily due to the authors engaging in the conversations around the issues posted, giving good feedback and also thoroughly reviewing changes and adding their preferences to them. This has been a surprisingly uncommon experience in my short time as an open source contributor, but I am hoping this is what I encounter more often than not in working as a community.

The 2 functions I originally setout to add to this project have both been merged into the main program and can be found in the config.py module. These functions allow users to export and import their program configuration settings to/from .yaml files.

As these settings exist in a series of global variables in the config.py file, exporting the settings was as simple as mapping the variables into an “config” object, formatted such that could be passed to the yaml.dump() function which would write the config object to a YAML file. I have found that Python has a great deal of libraries and modules available that can provide a lot of functionality that I may have previously done manually. In this case, importing the yaml and toml modules made light work of writing and reading from files. As well, the argparse module was used in this project which is one of the most helpful library tools I’ve run across. It makes light work of processing command line arguments at runtime.

The import function also used the yaml module, this time yaml.safe_load() function. This was used to read an existing yaml configuration file and load its specific values into the current settings to run the program. So similar to the export process, the object that was created using yaml.safe_load() was then mapped back to populate the global variables that represent the programs configuration settings. This turned out to be a much easier process than I realized in the beginning.

As an addition, to the scope of work I originally planned to complete, I decided that providing some unit tests for my work, would help in developing a more complete contribution process. No public facing testing code had yet been added to this projects repo, so perhaps, unit tests for these functions would be a good jumping off point to make the creation of unit tests an ongoing step in the integration of new features and contributions. Time will tell if that is the case, but I’m very happy with how my work has added to this project to date and it is very rewarding to see some substantial code contributions merged into the main project.

NeoGPT contributions continued...

Bryce Seefieldt — Tue, 09 Jan 2024 18:43:55 +0000

I have made good progress in my contribution pans for the NeoGPT project as discussed in my previous post “Escalating NeoGPT contribution”. I was able to work through my first goal of adding command line switches for the export functionality in my most recent Pull Request which was successfully merged into the main branch of the project.

This PR also included some enhancements to the original export_config() function which I created, that provides some level of sanitization of the optional filename parameters which the user can provide along with the --export argument. Essentially, if a string ( representing the config filename) is provided by the user (overriding the default config filename to be written) then the export function forces a .yaml file format. In addition, it enforces some checks to provide a new filename if the provided filename is attempting to overwrite an existing config file of the same name. These changes were all wrapped into the now merged PR.

In reviewing my export configuration process, the project author was able to extrapolate much of the functionality and transpose it to the load configuration process, which was my planned next step. As they have provided the initial framework for the load_config() function I set out to create, I am now going through it to add some similar validation enhancements to those discussed above, as well as to test the functionality and provide any necessary debugging.

As much of the intended scope initially laid out is near completion, I have discussed with the project author, implementing some unit test suites for the functionality I have introduced, to be included in the ongoing contribution QA process, and for future inclusion in the introduction of some CI/CD workflows into the project. I will continue to update on the process as I introduce unit tests into my previous work.

Escalating NeoGPT contribution

Bryce Seefieldt — Mon, 01 Jan 2024 19:18:55 +0000

I am continuing to build on my work on the NeoGPT customizable GPT chatbot project. My last efforts were focused on creating a function that can read the current program configurations and export them to a yaml file. I created this function based on the parameters defined in the existing config.py module which was called in the main.py program at runtime in order to establish the current configuration details to define how the current session will be run.

The implementation of the export_config function required reading settings defined in both config.py as well as the pyproject.toml file to be able to capture a snapshot of a variety of configuration parameters at the time the export_config function is called.

To expand on my contribution to this project I have conferred with the project author to determine some next steps required to allow this function to be utilized as well as to add the functionality that allows the configuration yaml files to be read and parsed in order to load the configuration settings saved in the yaml file, such that the program build is configured to the saved settings.
The requirements to implement this expanded functionality include:

Adding a -export config_x.yml command line switch that executes the export_config function from CLI and allows the user to define the yaml filename in which to save the current config settings.
Define a load_config function that can be called to read a specified yaml configuration file and load the defined settings to overwrite the current build configuration.
Adding an -load config_x.yml command line switch that executes the load_config function from CLI and allows the user to define the file which should be read in order to update/overwrite the current config settings.

This will require a deeper analysis of the projects source code. Creating the export_config function only required scraping the value of various parameters defined in config.py and pyproject.toml and writing them to file in the required format. These next steps however will require looking at each step of the programs build and run process, assessing the methods used to set each individual configuration parameter and passing the saved parameters to each individual method such that it overwrites the current settings with the stored value.
This should be an interesting deep-dive into the program that will give me a much better understanding of a significant portion of this programs executable codebase.

Digging deeper into NeoGPT

Bryce Seefieldt — Wed, 13 Dec 2023 15:18:32 +0000

I had a chance to revisit and contribute some more functionality to NeoGPT, a customizable GPT chatbot program written in Python. It was nice to be able to do some more work on this project as the initial time invested in setting up the source code locally and create my build was significant compared to the actual contribution I made. Whereas my first contribution for Hacktoberfest, was a simple bash script to streamline the build process, this time around I was able to dive deeper into the actual program and develop some functionality to allow the user to export the current program configuration settings.

I am sure the experience of contributing to open source projects can vary dramatically depending on the project, how many owners and full-time contributors are involved, among a number of other variables. My experience so far, in terms of the process of responding to issues posted by the project owners, has been more frustrating than rewarding. I am finding in many cases that the posted issues often lack a great deal of necessary detail that would seem to be important for an outside developer to attempt to solve. Even when I have assessed the issue, explored the code, and made requests for clarification as to the desired approach to the solution, or just asked some specific questions to better understand the code and/or the task at hand, I feel like the responses are brief and often lack the insight and clarity that my initial inquiries were attempting to elicit.

Perhaps it’s my level of comprehension being lower than that of the project developers, but my feeling is that if someone were to reach out to me with questions on how to contribute to my project, I would want to be as detailed as possible in my responses to avoid any confusion and to facilitate a functional contribution that aligns with my intentions and expectations. I’m sure this won’t always be the case, but that’s just my observational rant as I continue to work towards an effective contribution on what is the most complex codebase I have yet to engage with. This gives me some insight into the standard I would like to hold myself to in the future, if and when I begin sharing projects and accepting contributions from previously unfamiliar developers.

In my specific efforts this week, as I mentioned, I am developing a function to read and store the current configuration settings for the NeoGPT chatbot. The biggest challenge in doing so is that the settings can vary dramatically depending on the command line arguments being provided at runtime among a number of other variables. As well, those settings are not necessarily stored or logged in one central location. Due to this, there was a great deal of code analysis required to try and determine when the settings parameters are established and how to access them from a helper function.

One of the biggest questions this raised was when and how should the code be calling the export function, as the current state of the program at the time it calls the function has a significant impact on how I should write the function. While I have tried to ask the right questions to gain clarity on this, the answer is still not clear to me. I’ve been able to partially address the scope of the issue and generate a draft pull request that presents my progress while attempting to elicit some feedback to get to the desired solution.

PyPI Packaging

Bryce Seefieldt — Wed, 13 Dec 2023 15:15:03 +0000

Hey guys, I hate to brag but I’m officially a published author! That’s right I published my Python ez-txt2html converter to PyPi, and it was easy! Here’s how I did it.
First off, for simplicity sake, I did away with my src directory and instead moved all my py code into a directory named for my project (/ez-txt2html). Creating a directory named for your project is important when creating a build to upload to PyPi.

After some research into the process I decided to use hatch as the build backend, so I needed the package installed,which was as simple as pip install hatch

Next up I added some build related details to my pyproject.toml which included some version info, general project details as well as some instructions on how to create a build. Most importantly was adding:

 [build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

This directs the build function to use hatch to create a build of your package. In addition, I was receiving an error when trying to build that required I define what package should be targeted. This was done by adding the following to the pyproject.toml file:

[tool.hatch.build.targets.wheel]
packages = ["ez-txt2html"]

This is essentially just pointing to the newly created package directory. The result was the creation the /dist directory which contained the .whl and .tar.gz binary files which are what eventually get added to PyPi as your packages.

From there, I needed to learn a bit about PyPi or Python Package Index, which is the home for all the wonderful packages that you know if you have ever run the handy pip install command. PyPi has a pretty quick and easy onboarding, which requires a secured account be created and, for the purposes of submitting packages from CLI, an API token be generated. This can be done in your PyPi profile. Once logg just navigate to https://pypi.org/manage/account/ and scroll down to the API tokens section. Click “Add Token” and follow the few steps to generate an API token which is your access point to uploading packages.
With all this in place, I was able to use twine to handle the package upload. First I needed to install twine, again as simple as pip install twine. In order for twine to access my API token during the package upload process, it needed to read it from .pypirc file that contains the token info. For some that file may exist already, for me I was required to create it. Working in windows I simply used a text editor to create it in my home user directory ($HOME/.pypirc). The file contents had a TOML like format looked like this:

[pypi]
username = __token__
password = "your-PyPi-api-token"

And finally, the package could be uploaded using the command python -m twine upload --repository pypi dist/*
This uploads the contents of the project’s /dist directory to a PyPi and if all goes well, provides you with a link to your package page. Here, front and center is a handy command line that can be run on CLI. For those playing along at home run pip install ez-txt2html-bryce-seefieldt.
If I did my job right, this will download and install ez-txt2html as an executable and importable module in your Python environment. From their you can run python -m ez-txt2html.ez_txt2html -h to see the options for running the package from CLI. Like magic. What an accomplishment, if I do say so myself. I’ve passed this on to a couple of my devBuds and it seems to work for them NP – let me know if it works for you, or if you have any tips on how I could make this process smoother or smarter.

PyPI Packaging

Bryce Seefieldt — Wed, 13 Dec 2023 09:35:22 +0000

 [build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[tool.hatch.build.targets.wheel]
packages = ["ez-txt2html"]

[pypi]
username = __token__
password = "your-PyPi-api-token"

PyPI Packaging

Bryce Seefieldt — Wed, 13 Dec 2023 09:35:22 +0000

 [build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[tool.hatch.build.targets.wheel]
packages = ["ez-txt2html"]

[pypi]
username = __token__
password = "your-PyPi-api-token"

Frontend testing JSDOM web apps

Bryce Seefieldt — Sat, 09 Dec 2023 23:40:34 +0000

I have been working on expanding my understanding of creating test environemnts and developing tests for various languages. It’s a fascinating and challenging element of the development process that I have been wanting to explore for a long time now.

Having successfully created a test environment and written testing for my Python static site generator project, I thought it would be a good learning experience to implement testing for a different project that I have contributed to in the past. This RegEx Pro project is the front-end for a JavaScript web app that defines a number of tools to test and validate regular expressions against user input.

I decided to use the Jest testing framework to create a testing environment for the application. Going into this I had minimal familiarity with Jest and immediately, I realized that this task was venturing into unfamiliar territory in teerms of my understanding of testing front-end code. Specifically, the project has a fairly straightforward structure which utilizes JSDOM to render the web app. While the source code was simple and straightforward in it's method of rendering a UI, it presented a unique challenge in developing the appropriate test environment which needs to interact and render the DOM elements.

Investigating options for testing JSDOM with Jest was a surprisingly difficult task. I found that there is limited documentation on the basics of writing tests for JSDOM. What information I did find described many varied approaches to the problem. I came to realize there a quite a few frameworks and tools to address front-end JS testing, with widely varying methods. The documentation I found addressing this challenge was often beyond my level of comprehension and often addressed much more complex cases than I was attempting.

In the end, I found this article, Frontend testing in Node with jsdom by Oliver Jam which provided a very simple entry point to understanding front-end testing for JSDOM. In addition, it provided an example repo which creates simple but functional JSDOM test environment. Being able to work through the environemnt configuration on a fundamental level was extremely helpful in understanding the challenge I was facing and allowed me to make some progress towards my goal.

What I was able to implement is undoubtedly the first iteration in configuring an appropriate test environment. It can be reviewed here.
I would really appreciate any feedback on what I have implemented and suggestions on streamlining the configuration and the tests I’ve written so far. I still intend to work further to address code coverage, including more comprehensive integration testing and expanding the unit tests. This will require some further research on my part into testing user input cases.

Some of my key takeaways from the process so far:

The RegEx Pro application has an index.html entry point , which renders script.js as the landing page. The most challenging step in understanding the use of Jest for testing JSDOM elements was learning how to generate mock document objects which can be used to test the various JS modules independently.
The approach I took to address the creation of JSDOM objects for independent unit tests required a number of dependencies. In the end the following dev-dependencies were required in package.json:

  "devDependencies": {
    "@babel/core": "^7.23.5",
    "@babel/preset-env": "^7.23.5",
    "babel-jest": "^29.7.0",
    "jest": "^29.7.0",
    "jest-environment-jsdom": "^29.7.0",
    "jsdom": "^23.0.1",
    "jsdom-global": "^3.0.2",
    "text-encoding": "^0.7.0"
  }

A major hurdle that took quite a bit of trial and error to solve was Jest producing the following error at runtime: SyntaxError: Cannot use import statement outside a module Which was related to importing modules into .test.js files. It was solved by installing Babel and including the following .babelrc file in the project:

 {
    "presets": [
        "@babel/preset-env"
    ]
}

As well, the syntax for the test files, utilized the following code to initialize a document object that can be called within the test functions to render the applications various JSDOM components:

import { JSDOM } from "jsdom";
const dom = new JSDOM();
global.document = dom.window.document;

As my research continues into front-end testing I have read about a number of other approaches and frameworks that may facilitate JSDOM testing, including the Selenium framework which may offer some more comprehensive tools for integration testing and CI workflows. I will continue to post updates as I refine and expand my initial testing for this project.

CI using GitHub Actions

Bryce Seefieldt — Sat, 09 Dec 2023 20:40:58 +0000

I set out to add further development and contribution tools to my ez-txt2html converter. Specifically, I wanted to introduce an initial Continuous Integration workflow. For this, I used the “Python Application” workflow template in Github Actions to create a CI testing workflow that builds a Py v3.12 environments, builds the project dependencies, runs Flake8 linting and Black formatting and then subsequently runs PyTest using the test suites I’ve written previously.

What was generated after confirming the details by which to build the workflow was a YAML file that defined:

what actions should trigger the workflow to run. In this case any push or PR to the main branch.
what OS the build environment should run on, defined as Ubuntu for this build.
what steps to execute in the build and workflow, including:
- run checkout v3 module.
- python version to be installed.
- process to install project dependencies.
- run linting.
- and run tests, in this case using PyTest.

Setting up this basic CI workflow was a breeze and was a process I feel I could have utilized many times in past projects to streamline additions to projects. It is fair to say my workflow used strictly defaults provided by the template, so there remains a great deal of exploration to be done, in terms of utilizing the full capabilities of GitHub Actions. I am very excited to expand my understanding how to harness the potential of CD and CI for greater efficiency and productivity. Rest assured I will post some updates as I explore further.

Over the last few weeks I have spent some time contributing testing functionality to a number of projects, which was met with with drastically different results. In an upcoming post, I will deep dive into exploration of setting up a Jest test environment and writing front-end testing for a JavaScript web application that I have contributed to in the past. I faced many challenges in this process, which I look forward to sharing soon.

On the other end of the frustration spectrum, I was able to look at what one of my peers has been doing with a similar static site generator (text to html converter) application. This is a TypeScript project I have also contributed some code to in the past, where I discussed some of the initial challenges of configuring the project environment, which required me to setup Windows Subsytem for Linux. This project utilized Bun as an alternative to node.js to build and run the application. While there was an initial implementation curve that took a lot of work to get through, however my current task of contributing some additional tests to the existing test suites, was seamless utilizing the tools provided by Bun. The simplicity and ease of Bun’s built-in test environment really made the process effortless. Now I was just adding to an exiting test setup, so I can’t speak on the process to get Bun configured, but writing and running test with the provided tools was very easy, particularly in comparison to configuring the PyTest environment for my project.

As I mentioned, I have a great deal of exploration to do in terms of code coverage for my projects and fully utilizing GitHub Actions, but what I have learned so far really feels like a major step towards understanding the full spectrum of developing and supporting open-source projects.

PyTest unit testing now underway

Bryce Seefieldt — Sat, 11 Nov 2023 04:56:25 +0000

I have now added some testing to my ez-txt2html converter.

I decided to use pytest as framework for running tests on this project. It seems like a popular choice for many Python developers. As I built tests I also took advantage of some of the tools available in the built-in Python module unittest. It’s mock() function provides some helpful ways of providing mock data in order to run tests on certain functions independently, hard coding variables from calling functions.

Pytest was an easy install, simple as pip install pytest and running it had a reasonable learning curve. I wrote test (.py) files in my src directory alongside my main module files, running them simply with CLI prompt pytest test_file.py and responding to any errors or warnings at runtime. I have some work to do to further refine my directory structure, but for now for simplicity on a small program, this was my cleanest approach.

The real work came from thinking through the types of tests needed for various processes and functions. There are a huge amount of variables and outcomes to think through. I found that searching testing examples that involve similar input/output types, common intention or have similar file and code structure is a good way to think of what some of the priority types of tests are. Ultimately it really does take a great deal of prioritization before jumping too heavily into the code.
In writing tests, I learned a lot about how isolate individual functions, and some of the more in-depth python theory around modularity. Thinking about a function being called and receiving explicit parameters when isolated from the main program, causes one to look at how certain functions can be designed differently. Also thinking about how you can assert outcomes that fulfill a tests purpose can be very difficult, especially when a function may interact with global variables or doesn’t return an objector variable?

While creating tests for functions involved in reading from file and converting text content to html, I was able to take a much more detailed look at the related algorithms and identify some output formatting inconsistencies. That would have been difficult to identify were I not going through the individual functions and trying to define what the expected output format should be. the biggest realization about writing tests was how important it is to understand and be able to exactly define the expected outcome/output of a program or function is, was probably the biggest realization about writing test.

Working with test suites, as with many additions relating to accommodating future development and contributions, really causes you to reassess and tidy things like file structure, naming conventions, modularity and so on. I've struggled to a degree with various environment configuration and path related challenges while trying to integrate more new tools, techniques, and workflows. It's a challenge but it's rewarding when you work through it.

Format and Lint for Python Open-Source

Bryce Seefieldt — Mon, 06 Nov 2023 19:46:01 +0000

This week I set out to make some changes to my source code environment to support contributors to the project. The main goal was to add a formatter and a linter to the environment to support consistent code formatting and layout as other developers contribute code changes.

To do this I worked with Black Formatter and Flake8 Linter as they were both tools I saw used frequently and with good feedback from Python developers. Both were very simple to install and implement.

Black

Black was a straightforward install pip install black from CLI.
Once installed it can be run on a .py file or set of directories containing files with the command black .\src\. from my project base directory. This formats every file in src directory and every child directory. Including a filename instead of “.” works on just the targeted file. The changes to the files are implemented and saved automatically.

Flake8

Flake8 required the exact same process to install and a slightly different process to run. From CLI python -m pip install flake8 installs the extension into your local environment or any virtual environment active where the install command was executed (this applies to the Black installation above as well).
Once installed I ran flake* .\src\. to lint all .py files in my src directory and its child folders. The same path changes can be made to apply flake8 to just a single file.

Rather than automatically editing and saving your files, flaked8 run from CLI provides a list of suggested changes for each file targeted, including the line and column number of the issue and a message describing the suggested edit. This can be altered in your editor and flake8 should be run repeatedly until you have satisfied all the suggested edits. If there is a particular issue you would like ignored when running the application, you can run flake8 --extend-ignore <<Error Code>> <<path/to/files>> instead.

VSCode Integration

Both of these tools offer VSCode extensions to simplify the process. They can be searched via the VSCode extensions window by typing Ctrl + Shift + X and searching “Black Formatter” and “Flake8” in the extensions sidebar. Just install and/or enable the extension. For Black I chose to apply the Black formatting automatically on save, this can be setup in VSCode Settings Ctrl + , and searching “format on save” – by selecting the format on save checkbox, Black automatically makes format changes to your .py files each time they are saved.

Conflicts

In addition to command line arguments that can be used to ignore or customize the format applied by both programs, you can also customize each application with settings in a pyproject.toml file.

I was actually running into a conflict between the default settings of Black and Flake8 that when used together actually had a disagreement as to what style to adhere to. Specifically the 2 tools enforced different defaults for maximum line length. So as Flake8 made a recommendation to shorten a line based on a smaller maximum line length setting, Black would immediately change the edits made upon saving the file.

To solve this I chose to reduce the line-length default in Black to match that of Flake8. I did this by simply adding the following code to my “pyproject.toml” file.

[tool.black] 
line-length = 79

Results

The format changes that Black made to my code were minor although they did implement the consistency desired from its use.

The majority of the changes made by Black were:

Changing all single quotes to double quotes.
Adding an extra blank line between functions.
Corrected a few instances of incorrect indentation.

Flake8 suggested a number of edits as well some of those included

missing whitespace around operator
blank line contains whitespace
line too long (91 > 79 characters)
continuation line under-indented for visual indent
missing whitespace after ','OR ‘(‘
expected 2 blank lines, found 1
too many blank lines (2)
f-string is missing placeholders
no newline at end of file

While not consequential to the functionality of the code, the changes enforced by these 2 applications adds a great deal of conformity to all code, and can really ease the burden and concern one has when seeking outside contribution to your project. It takes a great deal of the guess work out of assessing and accepting edits made by others and certainly reduces the amount of potential conflicts presented by git when attempting to merge the contributions. This way everyone can focus more on the quality of code rather than style guide adherence.

While all of this was very straightforward to implement, I also wanted to simplify and streamline the setup of these tools for contributors setting up the project for the first time, as well as a single command option for running the tools against edited files.

At the end of the day this was an easy task that I tackled by creating stand alone python scripts that run a series of executables. For example, format.py was a simple way to run both Black and Flake8 on the entire source code.

While this ended up being the easy option, the truth is that it took me days diving down a best practices rabbit hole. Something about the prospect of preparing my project to facilitate ease of contribution drove me to get into some deep weeds about how to best setup python projects for open source from the initial stages. This fueled an exhausting dive into researching virtual environments, setuptools, packaging py projects, and various other approaches to building open source py projects and providing intuitive build processes that simplify setup, execution, and contribution process.

Being that I just pulled myself out of that rabbit hole and settled on simply providing some simple scripts to install dependencies and run formatters, I think the various take aways from this exhausting deep dive will have to wait for a future post, once I’ve had a little time to process and try out the many, varied methods out there.

HacktoberRest

Bryce Seefieldt — Wed, 01 Nov 2023 23:14:04 +0000

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.