After contributing to the documentation of both smaller and larger Open Source projects, I finally felt ready to take on code modifications. Therefore, in the third week of Hacktoberfest, I contributed a minor backend code change to Care, the capacity and patient management system of an Open Source Healthcare Organization.
Dev and staging instances for testing are automatically deployed on every commit to the develop and staging branches.
The staging instances are available at:
I worked on adding a new settings variable NOTIFICATION_RETENTION_DAYS (with the default of 30 days) to allow configurable time periods for deleting old notifications (issue #2528).
The original implementation ran a Celery task that deleted notifications older than 90 days on a daily basis (original feature PR).
Since the original Pull Request for the notification cleanup task was included in the issue description, I had a good idea of how to approach the coding process. Right from the start I knew that I had to do three things to integrate a new settings variable:
Declare the variable with a default of 30 days.
This step caused some confusion as I wasn't sure where to define the settings variable. Even after studying the project's structure, I found that there were numerous files responsible for managing settings variables. To clear up my doubts, I joined the company's Slack, introduced myself, and explained my question in detail. (Btw, I received a response from the creator almost immediately. The moral of the story: don't be shy & reach out to people in the community!)
Modify the delete_old_notifications() function to use the new settings variable instead of the hardcoded value.
Update the test case to use the new settings variable.
You can take a closer look at the changes in my commit: e1a3cec
Pt. 2: Setting up the development environment & Testing the changes
When the code modifications were completed, I started setting up the development environment to run the test case for the changes I have made. This was by far the most challenging step in the whole contribution process.
To run the test case I needed to run the backend using Docker. I closely followed the instructions in CONTRIBUTING.mdand Care's documentation to run the server. However, it couldn't run because the celery container the backend depended on was unhealthy (the project relies on multiple containers, so the make up command in the Makefile orchestrates the startup of six containers, including celery).
Upon checking the logs for the Celery container, I discovered that the container couldn't start because of the line-ending mismatch in the setup scripts (as I am working on a Windows machine, my scripts had been automatically converted from LF (Unix style) to CRLF (Windows style), which caused the container to fail when executing the scripts in a Linux environment).
To fix the issue, I manually modified the line endings of my scripts using a tool called dos2unix. I re-build the image and containers, but although the line ending error disappeared, the container was still unhealthy.
I was trying to debug the error and rebuilt the containers multiple times, making minor changes along the way. I even re-cloned the project to ensure that the line endings were untouched, but nothing seemed to work. This is when I decided to return to Slack for help. I started searching the channel to see if any other contributors had faced similar issues. After sifting through the messages using keywords, I found that the root of my problem was that the initial erroneous startup of the containers had created incorrect volumes. These erroneous volumes were preventing the celery container from performing necessary data migrations and, consequently, successfully starting.
Finally, I have deleted the volumes and restarted the containers... and everything started working as expected!
Then, I executed the test case on the backend container using docker compose exec (and was relieved to see that the test ran without any issues).
Pt. 3: Submitting my Pull Request
With my code change implemented and tested, I started working on the Pull Request. Fortunately, it was quite straightforward. (There were no complex guidelines to navigate, and I didn’t need to sign any license agreements.) I simply filled out the provided template with all the necessary information about my contribution and was ready to submit.(My PR: PR #2547)
Afterthoughts:
This experience reminded me not to shy away from seeking help from the community. Truth be told, someone has probably faced a similar issue before, so reaching out is certainly worth a shot!
